Re: [PATCH RFC v4 23/25] fs: start all kthreads in nullfs

[Zenghui Yu <yuzenghui@huawei.com>]

Hi Christian,

On 2026/6/1 21:56, Christian Brauner wrote:
> Point init_task's fs_struct (root and pwd) at a private nullfs instance
> instead of the mutable rootfs. All kthreads now start isolated in nullfs
> and must use scoped_with_init_fs() for any path resolution.
> 
> PID 1 is moved from nullfs into the initramfs by init_userspace_fs().
> Usermodehelper threads use userspace_init_fs via the umh flag in
> copy_fs(). All subsystems that need init's filesystem state for path
> resolution already use scoped_with_init_fs() from earlier commits in
> this series.
> 
> This isolates kthreads from userspace filesystem state and makes it
> hard to perform filesystem operations from kthread context.
> 
> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
> ---
>  fs/namespace.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index fe919abd2f01..43ca4838d451 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -6173,12 +6173,14 @@ static void __init init_mount_tree(void)
>  	struct path root;
>  
>  	/*
> -	 * We create two mounts:
> +	 * We create three mounts:
>  	 *
>  	 * (1) nullfs with mount id 1
>  	 * (2) mutable rootfs with mount id 2
> +	 * (3) private nullfs for kthreads (SB_KERNMOUNT)
>  	 *
> -	 * with (2) mounted on top of (1).
> +	 * with (2) mounted on top of (1). The init_task's root and pwd
> +	 * are pointed at (3) so all kthreads start isolated in nullfs.
>  	 */
>  	nullfs_mnt = vfs_kern_mount(&nullfs_fs_type, 0, "nullfs", NULL);
>  	if (IS_ERR(nullfs_mnt))
> @@ -6218,12 +6220,14 @@ static void __init init_mount_tree(void)
>  		init_mnt_ns.nr_mounts++;
>  	}

|	LOCK_MOUNT_EXACT(mp, &root);
|	if (unlikely(IS_ERR(mp.parent)))
|		panic("VFS: Failed to mount rootfs on nullfs");
|	scoped_guard(mount_writer)
|		attach_mnt(real_mount(mnt), mp.parent, mp.mp);

>  
> +	nullfs_mnt = kern_mount(&nullfs_fs_type);
> +	if (IS_ERR(nullfs_mnt))
> +		panic("VFS: Failed to create private nullfs instance");
> +	root.mnt	= nullfs_mnt;
> +	root.dentry	= nullfs_mnt->mnt_root;

The following lockdep splat can be triggered on mainline, which is built
with arm64's defconfig plus

	CONFIG_SHRINKER_DEBUG
	CONFIG_PROVE_LOCKING
	CONFIG_FTRACE

.  Reverting this patch (as pointed out by AI) makes this warn disappear.
Please have a look :-) .

Thanks,
Zenghui

---8<---

 ======================================================
 WARNING: possible circular locking dependency detected
 7.3.0-rc3+ #17 Not tainted
 ------------------------------------------------------
 rasdaemon/4449 is trying to acquire lock:
 ffff80008246cb78 (namespace_sem){++++}-{4:4}, at: lock_mount_exact+0x4c/0x308

 but task is already holding lock:
 ffff002080496980 (&sb->s_type->i_mutex_key#17){++++}-{4:4}, at: lock_mount_exact+0x3c/0x308

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #3 (&sb->s_type->i_mutex_key#17){++++}-{4:4}:
        down_read+0x48/0x164
        lookup_slow+0x30/0x68
        lookup_noperm_unlocked+0x58/0x5c
        debugfs_change_name+0xd4/0x33c
        shrinker_debugfs_rename+0xa8/0x118
        setup_bdev_super+0x130/0x260
        get_tree_bdev_flags+0x12c/0x1ec
        get_tree_bdev+0x14/0x20
        ext4_get_tree+0x18/0x24
        vfs_get_tree+0x28/0xec
        path_mount+0x3ec/0xbb8
        __arm64_sys_mount+0x190/0x2d8
        invoke_syscall+0x54/0x110
        el0_svc_common.constprop.0+0x40/0xe0
        do_el0_svc+0x1c/0x28
        el0_svc+0x4c/0x3a4
        el0t_64_sync_handler+0xa0/0xe4
        el0t_64_sync+0x198/0x19c

 -> #2 (shrinker_mutex){+.+.}-{4:4}:
        __mutex_lock+0x90/0x870
        mutex_lock_nested+0x24/0x30
        shrinker_alloc+0x158/0x4a0
        sget_fc+0x2fc/0x7b8
        get_tree_nodev+0x2c/0xb8
        nullfs_fs_get_tree+0x18/0x24
        vfs_get_tree+0x28/0xec
        vfs_kern_mount.part.0+0xcc/0x130
        mnt_init+0x12c/0x470
        vfs_caches_init+0x120/0x294
        start_kernel+0x824/0x93c
        __primary_switched+0x88/0x90

 -> #1 (&type->s_umount_key#2/1){+.+.}-{4:4}:
        down_write_nested+0x34/0xcc
        sget_fc+0x14c/0x7b8
        get_tree_nodev+0x2c/0xb8
        nullfs_fs_get_tree+0x18/0x24
        vfs_get_tree+0x28/0xec
        vfs_kern_mount.part.0+0xcc/0x130
        mnt_init+0x2b0/0x470			-> kern_mount()
        vfs_caches_init+0x120/0x294
        start_kernel+0x824/0x93c
        __primary_switched+0x88/0x90

 -> #0 (namespace_sem){++++}-{4:4}:
        __lock_acquire+0x1490/0x21b8
        lock_acquire+0x1d8/0x404
        down_write+0x38/0xd0
        lock_mount_exact+0x4c/0x308
        finish_automount+0x70/0x134
        __traverse_mounts+0xd4/0x22c
        step_into_slowpath+0x2ec/0x390
        path_openat+0x2b0/0x8d4
        do_file_open+0x98/0x158
        do_sys_openat2+0x78/0xfc
        __arm64_sys_openat+0x70/0xbc
        invoke_syscall+0x54/0x110
        el0_svc_common.constprop.0+0x40/0xe0
        do_el0_svc+0x1c/0x28
        el0_svc+0x4c/0x3a4
        el0t_64_sync_handler+0xa0/0xe4
        el0t_64_sync+0x198/0x19c

 other info that might help us debug this:

 Chain exists of:
   namespace_sem --> shrinker_mutex --> &sb->s_type->i_mutex_key#17

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&sb->s_type->i_mutex_key#17);
                                lock(shrinker_mutex);
                                lock(&sb->s_type->i_mutex_key#17);
   lock(namespace_sem);

  *** DEADLOCK ***

 locks held by rasdaemon/4449: 1, last CPU#95:
  #0: ffff002080496980 (&sb->s_type->i_mutex_key#17){++++}-{4:4}, at: lock_mount_exact+0x3c/0x308

 stack backtrace:
 CPU: 95 UID: 0 PID: 4449 Comm: rasdaemon Not tainted 7.3.0-rc3+ #17 PREEMPT
 Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019
 Call trace:
  show_stack+0x18/0x24 (C)
  dump_stack_lvl+0x90/0xd0
  dump_stack+0x18/0x24
  print_circular_bug+0x294/0x378
  check_noncircular+0x164/0x178
  __lock_acquire+0x1490/0x21b8
  lock_acquire+0x1d8/0x404
  down_write+0x38/0xd0
  lock_mount_exact+0x4c/0x308
  finish_automount+0x70/0x134
  __traverse_mounts+0xd4/0x22c
  step_into_slowpath+0x2ec/0x390
  path_openat+0x2b0/0x8d4
  do_file_open+0x98/0x158
  do_sys_openat2+0x78/0xfc
  __arm64_sys_openat+0x70/0xbc
  invoke_syscall+0x54/0x110
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x4c/0x3a4
  el0t_64_sync_handler+0xa0/0xe4
  el0t_64_sync+0x198/0x19c