kernel/linux.git/fs/notify, branch master

Merge tag 'fsnotify_for_v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs

2026-04-16T02:18:51+00:00

Pull fsnotify updates from Jan Kara: "A couple of small fsnotify fixes and cleanups" * tag 'fsnotify_for_v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2} fsnotify: inotify: pass mark connector to fsnotify_recalc_mask() fanotify: call fanotify_events_supported() before path_permission() and security_path_notify() fanotify: avoid/silence premature LSM capability checks inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails

fanotify: replace deprecated strcpy in fanotify_info_copy_{name,name2}

2026-03-23T09:10:59+00:00

strcpy() has been deprecated [1] because it performs no bounds checking on the destination buffer, which can lead to buffer overflows. Replace it with the safer strscpy(). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1] Signed-off-by: Thorsten Blum Link: https://patch.msgid.link/20260321210544.519259-4-thorsten.blum@linux.dev Signed-off-by: Jan Kara

treewide: change inode->i_ino from unsigned long to u64

2026-03-06T13:31:28+00:00

On 32-bit architectures, unsigned long is only 32 bits wide, which causes 64-bit inode numbers to be silently truncated. Several filesystems (NFS, XFS, BTRFS, etc.) can generate inode numbers that exceed 32 bits, and this truncation can lead to inode number collisions and other subtle bugs on 32-bit systems. Change the type of inode->i_ino from unsigned long to u64 to ensure that inode numbers are always represented as 64-bit values regardless of architecture. Update all format specifiers treewide from %lu/%lx to %llu/%llx to match the new type, along with corresponding local variable types. This is the bulk treewide conversion. Earlier patches in this series handled trace events separately to allow trace field reordering for better struct packing on 32-bit. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260304-iino-u64-v3-12-2257ad83d372@kernel.org Acked-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Chuck Lever Signed-off-by: Christian Brauner

fsnotify: inotify: pass mark connector to fsnotify_recalc_mask()

2026-02-26T14:19:31+00:00

fsnotify_recalc_mask() expects a plain struct fsnotify_mark_connector *, but inode->i_fsnotify_marks is an __rcu pointer. Use fsn_mark->connector instead to avoid sparse "different address spaces" warnings. Signed-off-by: Sun Jian Link: https://patch.msgid.link/20260214051217.1381363-1-sun.jian.kdev@gmail.com Signed-off-by: Jan Kara

fanotify: call fanotify_events_supported() before path_permission() and security_path_notify()

2026-02-26T14:18:41+00:00

The latter trigger LSM (e.g. SELinux) checks, which will log a denial when permission is denied, so it's better to do them after validity checks to avoid logging a denial when the operation would fail anyway. Fixes: 0b3b094ac9a7 ("fanotify: Disallow permission events for proc filesystem") Signed-off-by: Ondrej Mosnacek Reviewed-by: Amir Goldstein Reviewed-by: Paul Moore Link: https://patch.msgid.link/20260216150625.793013-3-omosnace@redhat.com Signed-off-by: Jan Kara

fanotify: avoid/silence premature LSM capability checks

2026-02-26T14:18:31+00:00

Make sure calling capable()/ns_capable() actually leads to access denied when false is returned, because these functions emit an audit record when a Linux Security Module denies the capability, which makes it difficult to avoid allowing/silencing unnecessary permissions in security policies (namely with SELinux). Where the return value just used to set a flag, use the non-auditing ns_capable_noaudit() instead. Fixes: 7cea2a3c505e ("fanotify: support limited functionality for unprivileged users") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Reviewed-by: Amir Goldstein Link: https://patch.msgid.link/20260216150625.793013-2-omosnace@redhat.com Signed-off-by: Jan Kara

inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails

2026-02-26T14:11:50+00:00

When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path. Fixes: 1cce1eea0aff ("inotify: Convert to using per-namespace limits") Cc: stable@vger.kernel.org Signed-off-by: Chia-Ming Chang Signed-off-by: robbieko Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260224093442.3076294-1-chiamingc@synology.com Signed-off-by: Jan Kara

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

fsnotify: Use connector list for destroying inode marks

2026-01-23T12:26:37+00:00

Instead of iterating all inodes belonging to a superblock to find inode marks and remove them on umount, iterate all inode connectors for the superblock. This may be substantially faster since there are generally much less inodes with fsnotify marks than all inodes. It also removes one use of sb->s_inodes list which we strive to ultimately remove. Reviewed-by: Amir Goldstein Reviewed-by: Christian Brauner Signed-off-by: Jan Kara