summaryrefslogtreecommitdiff
path: root/fs
AgeCommit message (Collapse)Author
2026-01-16ntfs3: Restore NULL folio initialization in ntfs_writepages()Nathan Chancellor
Clang warns (or errors with CONFIG_WERROR=y): fs/ntfs3/inode.c:1021:6: error: variable 'folio' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] 1021 | if (is_resident(ni)) { | ^~~~~~~~~~~~~~~ fs/ntfs3/inode.c:1024:48: note: uninitialized use occurs here 1024 | while ((folio = writeback_iter(mapping, wbc, folio, &err))) | ^~~~~ folio should be initialized to NULL for the first iteration of writeback_iter() to start the loop properly. Restore the NULL initialization of folio that was lost in the recent iomap conversion to clear up the warning. Fixes: 099ef9a ("fs/ntfs3: implement iomap-based file operations") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/oe-kbuild-all/202601010644.FIhOXy6Y-lkp@intel.com/ Closes: https://lore.kernel.org/r/202601010513.axd56bks-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> [almaz.alexandrovich@paragon-software.com: added a few more tags] Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-16quota: fix livelock between quotactl and freeze_superAbhishek Bapat
When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze. However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled. The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync. This results in a hang of the freezer process and 100% CPU usage by the quota process. While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU: # mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount # mount /dev/sda -o quota,usrquota,grpquota a_mount # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \ xfs_freeze -u a_mount; done" & # taskset -c 3 bash -c "while true; do quotaon a_mount; \ quotaoff a_mount; done" & Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete. Fixes: 576215cffdef ("fs: Drop wait_unfrozen wait queue") Signed-off-by: Abhishek Bapat <abhishekbapat@google.com> Link: https://patch.msgid.link/20260115213103.1089129-1-abhishekbapat@google.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-01-16fuse: use private naming for fuse hash sizeJens Axboe
With a mix of include dependencies, the compiler warns that: fs/fuse/dir.c:35:9: warning: ?HASH_BITS? redefined 35 | #define HASH_BITS 5 | ^~~~~~~~~ In file included from ./include/linux/io_uring_types.h:5, from ./include/linux/bpf.h:34, from ./include/linux/security.h:35, from ./include/linux/fs_context.h:14, from fs/fuse/dir.c:13: ./include/linux/hashtable.h:28:9: note: this is the location of the previous definition 28 | #define HASH_BITS(name) ilog2(HASH_SIZE(name)) | ^~~~~~~~~ fs/fuse/dir.c:36:9: warning: ?HASH_SIZE? redefined 36 | #define HASH_SIZE (1 << HASH_BITS) | ^~~~~~~~~ ./include/linux/hashtable.h:27:9: note: this is the location of the previous definition 27 | #define HASH_SIZE(name) (ARRAY_SIZE(name)) | ^~~~~~~~~ Hence rename the HASH_SIZE/HASH_BITS in fuse, by prefixing them with FUSE_ instead. Signed-off-by: Jens Axboe <axboe@kernel.dk> Link: https://patch.msgid.link/195c9525-281c-4302-9549-f3d9259416c6@kernel.dk Acked-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-16posix_acl: make posix_acl_to_xattr() alloc the bufferMiklos Szeredi
Without exception all caller do that. So move the allocation into the helper. This reduces boilerplate and removes unnecessary error checking. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Link: https://patch.msgid.link/20260115122341.556026-1-mszeredi@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-16Revert "f2fs: block cache/dio write during f2fs_enable_checkpoint()"Chao Yu
This reverts commit 196c81fdd438f7ac429d5639090a9816abb9760a. Original patch may cause below deadlock, revert it. write remount - write_begin - lock_page --- lock A - prepare_write_begin - f2fs_map_lock - f2fs_enable_checkpoint - down_write(cp_enable_rwsem) --- lock B - sync_inode_sb - writepages - lock_page --- lock A - down_read(cp_enable_rwsem) --- lock A Cc: stable@kernel.org Fixes: 196c81fdd438 ("f2fs: block cache/dio write during f2fs_enable_checkpoint()") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-01-15Merge tag 'nfs-for-6.19-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds
Pull NFS client fixes from Trond Myklebust: - Fix another deadlock involving nfs_release_folio() - localio: - Stop I/O upon hitting a fatal error - Deal with page offsets that are > PAGE_SIZE - Fix size read races in truncate, fallocate and copy offload - Several bugfixes for the NFSv4.x directory delegation client code - pNFS: - Fix a deadlock when returning delegations during open - Fix memory leaks in various error paths * tag 'nfs-for-6.19-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFS: Fix size read races in truncate, fallocate and copy offload NFS: Don't immediately return directory delegations when disabled NFS/localio: Deal with page bases that are > PAGE_SIZE NFS/localio: Stop further I/O upon hitting an error NFSv4.x: Directory delegations don't require any state recovery NFSv4: Don't free slots prematurely if requesting a directory delegation NFSv4: Fix nfs_clear_verifier_delegated() for delegated directories NFS: Fix directory delegation verifier checks pnfs/blocklayout: Fix memory leak in bl_parse_scsi() pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() NFS: Fix a deadlock involving nfs_release_folio() pNFS: Fix a deadlock when returning a delegation during open()
2026-01-15NFS: Fix size read races in truncate, fallocate and copy offloadTrond Myklebust
If the pre-operation file size is read before locking the inode and quiescing O_DIRECT writes, then nfs_truncate_last_folio() might end up overwriting valid file data. Fixes: b1817b18ff20 ("NFS: Protect against 'eof page pollution'") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2026-01-15ntfs3: Refactor duplicate kmemdup pattern in do_action()Baolin Liu
Extract the repeated pattern of duplicating attribute and updating OpenAttr into a helper function to reduce code duplication and improve maintainability. Signed-off-by: Baolin Liu <liubaolin@kylinos.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15fs/ntfs3: prevent infinite loops caused by the next valid being the sameEdward Adam Davis
When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1]. Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this. [1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244 inode_lock include/linux/fs.h:1027 [inline] ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: syzbot+bcf9e1868c1a0c7e04f1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bcf9e1868c1a0c7e04f1 Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15fs/ntfs3: make ntfs_writeback_ops staticsunliming
Fix below sparse warnings: fs/ntfs3/inode.c:972:34: sparse: sparse: symbol 'ntfs_writeback_ops' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601061424.nbKLNwC5-lkp@intel.com/ Signed-off-by: sunliming <sunliming@kylinos.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-15ntfs3: fix circular locking dependency in run_unpack_exSzymon Wilczek
Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock. The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone(). This creates an AB-BA deadlock. Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock. Reported-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Tested-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d27edf9f96ae85939222 Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-01-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc5Alexei Starovoitov
Cross-merge BPF and other fixes after downstream PR. No conflicts. Adjacent: Auto-merging MAINTAINERS Auto-merging Makefile Auto-merging kernel/bpf/verifier.c Auto-merging kernel/sched/ext.c Auto-merging mm/memcontrol.c Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-14ecryptfs: Annotate struct ecryptfs_message with __counted_byThorsten Blum
Add the __counted_by() compiler attribute to the flexible array member 'data' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Tyler Hicks <code@tyhicks.com> Link: https://patch.msgid.link/20260112115314.739612-2-thorsten.blum@linux.dev Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14btrfs: remove zoned statistics from sysfsJohannes Thumshirn
Remove the newly introduced zoned statistics from sysfs, as sysfs can only show a single page this will truncate the output on a busy filesystem. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-01-14btrfs: use may_create_dentry() in btrfs_mksubvol()Filipe Manana
There is no longer the need to use btrfs_may_create(), which was a copy of the VFS private function may_create(), since now that functionality is exported by the VFS as a function named may_create_dentry(). So change btrfs_mksubvol() to use the VFS function and remove btrfs_may_create(). Note that the btrfs copy was missing an audit_inode_child() call that we have in the VFS function. This only reinforces the need to use a common function, as it's very easy for the btrfs copy to get out of sync and therefore a maintenance burden. Signed-off-by: Filipe Manana <fdmanana@suse.com> Link: https://patch.msgid.link/adf8c802c77ec1c855ea9fe12491120ccc29a294.1768307858.git.fdmanana@suse.com Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14btrfs: use may_delete_dentry() in btrfs_ioctl_snap_destroy()Filipe Manana
There is no longer the need to use btrfs_may_delete(), which was a copy of the VFS private function may_delete(), since now that functionality is exported by the VFS as a function named may_delete_dentry(). In fact our local copy of may_delete() lacks an update that happened to that function which is point number 7 in that function's comment: "7. If the victim has an unknown uid or gid we can't change the inode." which corresponds to this code: /* Inode writeback is not safe when the uid or gid are invalid. */ if (!vfsuid_valid(i_uid_into_vfsuid(idmap, inode)) || !vfsgid_valid(i_gid_into_vfsgid(idmap, inode))) return -EOVERFLOW; As long as we keep a separate copy, duplicating code, we are also prone to updates to the VFS being missed in our local copy. So change btrfs_ioctl_snap_destroy() to use the VFS function and remove btrfs_may_delete(). Signed-off-by: Filipe Manana <fdmanana@suse.com> Link: https://patch.msgid.link/46b13dc5c957deb72a7f085916757a20878a8e73.1768307858.git.fdmanana@suse.com Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: export may_create() as may_create_dentry()Filipe Manana
For many years btrfs as been using a copy of may_create() in fs/btrfs/ioctl.c:btrfs_may_create(). Everytime may_create() is updated we need to update the btrfs copy, and this is a maintenance burden. Currently there are minor differences between both because the btrfs side lacks updates done in may_create(). Export may_create() so that btrfs can use it and with the less generic name may_create_dentry(). Signed-off-by: Filipe Manana <fdmanana@suse.com> Link: https://patch.msgid.link/ce5174bca079f4cdcbb8dd145f0924feb1f227cd.1768307858.git.fdmanana@suse.com Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: export may_delete() as may_delete_dentry()Filipe Manana
For many years btrfs as been using a copy of may_delete() in fs/btrfs/ioctl.c:btrfs_may_delete(). Everytime may_delete() is updated we need to update the btrfs copy, and this is a maintenance burden. Currently there are minor differences between both because the btrfs side lacks updates done in may_delete(). Export may_delete() so that btrfs can use it and with the less generic name may_delete_dentry(). While at it change the calls in vfs_rmdir() to pass a boolean literal instead of 1 and 0 as the last argument since the argument has a bool type. Signed-off-by: Filipe Manana <fdmanana@suse.com> Link: https://patch.msgid.link/e09128fd53f01b19d0a58f0e7d24739f79f47f6d.1768307858.git.fdmanana@suse.com Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14writeback: use round_jiffies_relative for dirtytime_workZhao Mengmeng
The dirtytime_work is a background housekeeping task that flushes dirty inodes, using round_jiffies_relative() will allow kernel to batch this work with other aligned system tasks, reducing power consumption. Signed-off-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn> Link: https://patch.msgid.link/20260113082614.231580-1-zhaomzhao@126.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14iomap: wait for batched folios to be stable in __iomap_get_folioChristoph Hellwig
__iomap_get_folio needs to wait for writeback to finish if the file requires folios to be stable for writes. For the regular path this is taken care of by __filemap_get_folio, but for the newly added batch lookup it has to be done manually. This fixes xfs/131 failures when running on PI-capable hardware. Fixes: 395ed1ef0012 ("iomap: optional zero range dirty folio processing") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260113153943.3323869-1-hch@lst.de Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: make insert_inode_locked() wait for inode destructionMateusz Guzik
This is the only routine which instead skipped instead of waiting. The current behavior is arguably a bug as it results in a corner case where the inode hash can have *two* matching inodes, one of which is on its way out. Ironing out this difference is an incremental step towards sanitizing the API. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20260114094717.236202-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: improve dump_inode() to safely access inode fieldsYuto Ohnuki
Use get_kernel_nofault() to safely access inode and related structures (superblock, file_system_type) to avoid crashing when the inode pointer is invalid. This allows the same pattern as dump_mapping(). Note: The original access method for i_state and i_count is preserved, as get_kernel_nofault() is unnecessary once the inode structure is verified accessible. Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Link: https://patch.msgid.link/20260112181443.81286-1-ytohnuki@amazon.com Reviewed-by: Mateusz Guzik <mjguzik@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: add <linux/init_task.h> for 'init_fs'Ben Dooks
The init_fs symbol is defined in <linux/init_task.h> but was not included in fs/fs_struct.c so fix by adding the include. Fixes the following sparse warning: fs/fs_struct.c:150:18: warning: symbol 'init_fs' was not declared. Should it be static? Fixes: 3e93cd671813e ("Take fs_struct handling to new file") Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://patch.msgid.link/20260108115856.238027-1-ben.dooks@codethink.co.uk Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: move initializing f_mode before file_ref_init()Amir Goldstein
The comment above file_ref_init() says: "We're SLAB_TYPESAFE_BY_RCU so initialize f_ref last." but file_set_fsnotify_mode() was added after file_ref_init(). Move it right after setting f_mode, where it makes more sense. Fixes: 711f9b8fbe4f4 ("fsnotify: disable pre-content and permission events by default") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://patch.msgid.link/20260109211536.3565697-1-amir73il@gmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14erofs: hold read context in iomap_iter if neededHongbo Li
Introduce `struct erofs_iomap_iter_ctx` to hold both `struct page *` and `void *base`, avoiding bogus use of `kmap_to_page()` in `erofs_iomap_end()`. With this change, fiemap and bmap no longer need to read inline data. Additionally, the upcoming page cache sharing mechanism requires passing the backing inode pointer to `erofs_iomap_{begin,end}()`, as I/O accesses must apply to backing inodes rather than anon inodes. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20260109102856.598531-3-lihongbo22@huawei.com Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14iomap: stash iomap read ctx in the private field of iomap_iterHongbo Li
It's useful to get filesystem-specific information using the existing private field in the @iomap_iter passed to iomap_{begin,end} for advanced usage for iomap buffered reads, which is much like the current iomap DIO. For example, EROFS needs it to: - implement an efficient page cache sharing feature, since iomap needs to apply to anon inode page cache but we'd like to get the backing inode/fs instead, so filesystem-specific private data is needed to keep such information; - pass in both struct page * and void * for inline data to avoid kmap_to_page() usage (which is bogus). Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20260109102856.598531-2-lihongbo22@huawei.com Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14fs: use nullfs unconditionally as the real rootfsChristian Brauner
Remove the "nullfs_rootfs" boot parameter and simply always use nullfs. The mutable rootfs will be mounted on top of it. Systems that don't use pivot_root() to pivot away from the real rootfs will have an additional mount stick around but that shouldn't be a problem at all. If it is we'll rever this commit. This also simplifies the boot process and removes the need for the traditional switch_root workarounds. Suggested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-13switch {alloc,free}_bprm() to CLASS()Al Viro
All linux_binprm instances come from alloc_bprm() and are unconditionally destroyed by free_bprm() in the end of the same scope. IOW, CLASS() machinery is a decent fit for those. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13do_execveat_common(): don't consume filename referenceAl Viro
... and convert its callers to CLASS(filename...) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13execve: fold {compat_,}do_execve{,at}() into their sole callersAl Viro
All of them are wrappers for do_execveat_common() and each has exactly one caller. The only difference is in the way they are constructing argv/envp arguments for do_execveat_common() and that's easy to do with less boilerplate. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13simplify the callers of alloc_bprm()Al Viro
alloc_bprm() starts with do_open_execat() and it will do the right thing if given ERR_PTR() for name. Allows to drop such checks in its callers... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13simplify the callers of do_open_execat()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13simplify the callers of file_open_name()Al Viro
It accepts ERR_PTR() for name and does the right thing in that case. That allows to simplify the logics in callers, making them trivial to switch to CLASS(filename). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13do_sys_openat2(): get rid of useless check, switch to CLASS(filename)Al Viro
do_file_open() will do the right thing when given ERR_PTR() as name... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13rename do_filp_open() to do_file_open()Al Viro
"filp" thing never made sense; seeing that there are exactly 4 callers in the entire tree (and it's neither exported nor even declared in linux/*/*.h), there's no point keeping that ugliness. FWIW, the 'filp' thing did originate in OSD&I; for some reason Tanenbaum decided to call the object representing an opened file 'struct filp', the last letter standing for 'position'. In all Unices, Linux included, the corresponding object had always been 'struct file'... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13do_filp_open(): DTRT when getting ERR_PTR() as pathnameAl Viro
The rest of the set_nameidata() callers treat IS_ERR(pathname) as "bail out immediately with PTR_ERR(pathname) as error". Makes life simpler for callers; do_filp_open() is the only exception and its callers would also benefit from such calling conventions change. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as nameAl Viro
no need to check in the caller Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13ksmbd_vfs_path_lookup(): vfs_path_parent_lookup() accepts ERR_PTR() as nameAl Viro
no need to check in the caller Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13move_mount(): filename_lookup() accepts ERR_PTR() as filenameAl Viro
no need to check it in the caller Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13file_setattr(): filename_lookup() accepts ERR_PTR() as filenameAl Viro
no need to check it in the caller Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13file_getattr(): filename_lookup() accepts ERR_PTR() as filenameAl Viro
no need to check it in the caller Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13struct filename ->refcnt doesn't need to be atomicAl Viro
... or visible outside of audit, really. Note that references held in delayed_filename always have refcount 1, and from the moment of complete_getname() or equivalent point in getname...() there won't be any references to struct filename instance left in places visible to other threads. Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13allow incomplete imports of filenamesAl Viro
There are two filename-related problems in io_uring and its interplay with audit. Filenames are imported when request is submitted and used when it is processed. Unfortunately, the latter may very well happen in a different thread. In that case the reference to filename is put into the wrong audit_context - that of submitting thread, not the processing one. Audit logics is called by the latter, and it really wants to be able to find the names in audit_context current (== processing) thread. Another related problem is the headache with refcounts - normally all references to given struct filename are visible only to one thread (the one that uses that struct filename). io_uring violates that - an extra reference is stashed in audit_context of submitter. It gets dropped when submitter returns to userland, which can happen simultaneously with processing thread deciding to drop the reference it got. We paper over that by making refcount atomic, but that means pointless headache for everyone. Solution: the notion of partially imported filenames. Namely, already copied from userland, but *not* exposed to audit yet. io_uring can create that in submitter thread, and complete the import (obtaining the usual reference to struct filename) in processing thread. Object: struct delayed_filename. Primitives for working with it: delayed_getname(&delayed_filename, user_string) - copies the name from userland, returning 0 and stashing the address of (still incomplete) struct filename in delayed_filename on success and returning -E... on error. delayed_getname_uflags(&delayed_filename, user_string, atflags) - similar, in the same relation to delayed_getname() as getname_uflags() is to getname() complete_getname(&delayed_filename) - completes the import of filename stashed in delayed_filename and returns struct filename to caller, emptying delayed_filename. CLASS(filename_complete_delayed, name)(&delayed_filename) - variant of CLASS(filename) with complete_getname() for constructor. dismiss_delayed_filename(&delayed_filename) - destructor; drops whatever might be stashed in delayed_filename, emptying it. putname_to_delayed(&delayed_filename, name) - if name is shared, stashes its copy into delayed_filename and drops the reference to name, otherwise stashes the name itself in there. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13switch __getname_maybe_null() to CLASS(filename_flags)Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13fs: hide names_cache behind runtime const machineryMateusz Guzik
s/names_cachep/names_cache/ for consistency with dentry cache. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13struct filename: saner handling of long namesAl Viro
Always allocate struct filename from names_cachep, long name or short; short names would be embedded into struct filename. Longer ones do not cannibalize the original struct filename - put them into kmalloc'ed buffers (PATH_MAX-sized for import from userland, strlen() + 1 - for ones originating kernel-side, where we know the length beforehand). Cutoff length for short names is chosen so that struct filename would be 192 bytes long - that's both a multiple of 64 and large enough to cover the majority of real-world uses. Simplifies logics in getname()/putname() and friends. [fixed an embarrassing braino in EMBEDDED_NAME_MAX, first reported by Dan Carpenter] Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13struct filename: use names_cachep only for getname() and friendsAl Viro
Instances of struct filename come from names_cachep (via __getname()). That is done by getname_flags() and getname_kernel() and these two are the main callers of __getname(). However, there are other callers that simply want to allocate PATH_MAX bytes for uses that have nothing to do with struct filename. We want saner allocation rules for long pathnames, so that struct filename would *always* come from names_cachep, with the out-of-line pathname getting kmalloc'ed. For that we need to be able to change the size of objects allocated by getname_flags()/getname_kernel(). That requires the rest of __getname() users to stop using names_cachep; we could explicitly switch all of those to kmalloc(), but that would cause quite a bit of noise. So the plan is to switch getname_...() to new helpers and turn __getname() into a wrapper for kmalloc(). Remaining __getname() users could be converted to explicit kmalloc() at leisure, hopefully along with figuring out what size do they really want - PATH_MAX is an overkill for some of them, used out of laziness ("we have a convenient helper that does 4K allocations and that's large enough, let's use it"). As a side benefit, names_cachep is no longer used outside of fs/namei.c, so we can move it there and be done with that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13getname_flags() massage, part 2Al Viro
Take the "long name" case into a helper (getname_long()). In case of failure have the caller deal with freeing the original struct filename. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13getname_flags() massage, part 1Al Viro
In case of long name don't reread what we'd already copied. memmove() it instead. That avoids the possibility of ending up with empty name there and the need to look at the flags on the slow path. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2026-01-13ntfs: ->d_compare() must not blockAl Viro
... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>