kernel/git/next/linux-next.git/fs/fs_struct.c, branch master

fs: stop rewriting paths for PF_EXITING | PF_DUMPCORE

2026-06-29T08:54:43+00:00

Skip exiting and core-dumping tasks when rewriting fs_struct paths in chroot_fs_refs(). Such a task is about to release its fs_struct via exit_fs() anyway, so the worst case is that it lingers on a stale root/pwd until it does. This isn't entirely free: a skipped task keeps its reference on the old root, so after a pivot_root() the old root can't be torn down until the task is gone. With umount2(MNT_DETACH) that only defers destruction of the old rootfs; a plain umount() could in principle fail with -EBUSY. In practice this doesn't matter -- pivot_root(2) is meant to be paired with MNT_DETACH and isn't issued while other tasks are actively using the mount namespace -- so the transient pin is harmless. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-25-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: stop rewriting kthread fs structs

2026-06-29T08:54:43+00:00

Now that we isolated kthreads filesystem state completely from userspace stop rewriting their state. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-24-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: make userspace_init_fs a dynamically-initialized pointer

2026-06-29T08:44:05+00:00

Change userspace_init_fs from a declared-but-unused extern struct to a dynamically initialized pointer. Add init_userspace_fs() which is called early in kernel_init() (PID 1) to record PID 1's fs_struct as the canonical userspace filesystem state. Wire up __override_init_fs() and __revert_init_fs() to actually swap current->fs to/from userspace_init_fs. Previously these were no-ops that stored current->fs back to itself. Fix nullfs_userspace_init() to compare against userspace_init_fs instead of &init_fs. When PID 1 unshares its filesystem state, revert userspace_init_fs to init_fs's root (nullfs) so that stale filesystem state is not silently inherited by kworkers and usermodehelpers. At this stage PID 1's fs still points to rootfs (set by init_mount_tree), so userspace_init_fs points to rootfs and scoped_with_init_fs() is functionally equivalent to its previous no-op behavior. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-5-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: add real_fs to track task's actual fs_struct

2026-06-29T08:43:45+00:00

Add a real_fs field to task_struct that always mirrors the fs field. This lays the groundwork for distinguishing between a task's permanent fs_struct and one that is temporarily overridden via scoped_with_init_fs(). When a kthread temporarily overrides current->fs for path lookup, we need to know the original fs_struct for operations like exit_fs() and unshare_fs_struct() that must operate on the real, permanent fs. For now real_fs is always equal to fs. It is maintained alongside fs in all the relevant paths: exit_fs(), unshare_fs_struct(), switch_fs_struct(), and copy_fs(). Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-4-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: notice when init abandons fs sharing

2026-06-29T08:38:48+00:00

PID 1 may choose to stop sharing fs_struct state with us. Either via unshare(CLONE_FS) or unshare(CLONE_NEWNS). Of course, PID 1 could have chosen to create arbitrary process trees that all share fs_struct state via CLONE_FS. This is a strong statement: We only care about PID 1 aka the thread-group leader so subthread's fs_struct state doesn't matter. PID 1 unsharing fs_struct state is a bug. PID 1 relies on various kthreads to be able to perform work based on its fs_struct state. Breaking that contract sucks for both sides. So just don't bother with extra work for this. No sane init system should ever do this. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-2-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: add switch_fs_struct()

2026-06-29T08:38:48+00:00

Don't open-code the guts of replacing current's fs struct. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-1-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fs: add for 'init_fs'

2026-01-14T15:50:37+00:00

The init_fs symbol is defined in 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 Link: https://patch.msgid.link/20260108115856.238027-1-ben.dooks@codethink.co.uk Reviewed-by: Jan Kara Signed-off-by: Christian Brauner

fs: inline current_umask() and move it to fs_struct.h

2025-11-05T21:51:23+00:00

There is no good reason to have this as a func call, other than avoiding the churn of adding fs_struct.h as needed. Signed-off-by: Mateusz Guzik Link: https://patch.msgid.link/20251104170448.630414-1-mjguzik@gmail.com Signed-off-by: Christian Brauner

fold fs_struct->{lock,seq} into a seqlock

2025-07-08T08:25:19+00:00

The combination of spinlock_t lock and seqcount_spinlock_t seq in struct fs_struct is an open-coded seqlock_t (see linux/seqlock_types.h). Combine and switch to equivalent seqlock_t primitives. AFAICS, that does end up with the same sequence of underlying operations in all cases. While we are at it, get_fs_pwd() is open-coded verbatim in get_path_from_fd(); rather than applying conversion to it, replace with the call of get_fs_pwd() there. Not worth splitting the commit for that, IMO... A bit of historical background - conversion of seqlock_t to use of seqcount_spinlock_t happened several months after the same had been done to struct fs_struct; switching fs_struct to seqlock_t could've been done immediately after that, but it looks like nobody had gotten around to that until now. Signed-off-by: Al Viro Link: https://lore.kernel.org/20250702053437.GC1880847@ZenIV Acked-by: Ahmed S. Darwish Acked-by: Peter Zijlstra (Intel) Reviewed-by: Christian Brauner Signed-off-by: Christian Brauner

kill do_each_thread()

2023-08-21T20:46:25+00:00

Eric has pointed out that we still have 3 users of do_each_thread(). Change them to use for_each_process_thread() and kill this helper. There is a subtle change, after do_each_thread/while_each_thread g == t == &init_task, while after for_each_process_thread() they both point to nowhere, but this doesn't matter. > Why is for_each_process_thread() better than do_each_thread()? Say, for_each_process_thread() is rcu safe, do_each_thread() is not. And certainly for_each_process_thread(p, t) { do_something(p, t); } looks better than do_each_thread(p, t) { do_something(p, t); } while_each_thread(p, t); And again, there are only 3 users of this awkward helper left. It should have been killed years ago and in fact I thought it had already been killed. It uses while_each_thread() which needs some changes. Link: https://lkml.kernel.org/r/20230817163708.GA8248@redhat.com Signed-off-by: Oleg Nesterov Reviewed-by: Kees Cook Cc: "Christian Brauner (Microsoft)" Cc: Eric W. Biederman Cc: Jiri Slaby # tty/serial Signed-off-by: Andrew Morton