Re: [linux-next:master] [fs] 313c47f4fe: BUG:kernel_hang_in_test_stage

hi, Christian Brauner,

On Tue, Feb 03, 2026 at 01:57:11PM +0100, Christian Brauner wrote:

[...]

> 
> I manually edited the job-script file to point to something existing on
> the server. If I delete everything that I did and restart the test using
> just the parameters and the job-script provided with your link then I
> run into the issues I mentioned in my first mail again...

[...]

> 
> 
> So I edit job-script and do:
> 
>         # export bm_initrd='/osimage/pkg/debian-x86_64-20180403.cgz/trinity-static-x86_64-x86_64-1c734c75-1_2020-01-06.cgz'
>         export bm_initrd='/osimage/pkg/debian-13-x86_64-20250902.cgz/trinity-x86_64-294c4652-1_20251011.cgz'
> 
> but that doesn't work because the glibc version is too old for the
> trinity test thing. So I switch to another bm_initrd:
> 
>         # original: export bm_initrd='/osimage/pkg/debian-x86_64-20180403.cgz/trinity-static-x86_64-x86_64-1c734c75-1_2020-01-06.cgz'
>         # export bm_initrd='/osimage/pkg/debian-13-x86_64-20250902.cgz/trinity-x86_64-294c4652-1_20251011.cgz'
>         export bm_initrd='/osimage/pkg/yocto-x86_64-minimal-20190520.cgz/trinity-static-x86_64-x86_64-1c734c75-1_2020-01-06.cgz'
> 
> And that one got it working and I managed to reproduce the issue.

oh, really sorry about this. this is our code issue. we will fix it.

> 
> The tests executes random VFS system calls including pivot_root(). I
> added debugging output into that system call:
> 
> And then it becomes clear:
> 
>         [   21.185641][ T5251] VFS: BEFORE PIVOT ROOT FROM /var/volatile/tmp to /var/volatile/tmp
>         [   21.185645][ T5251] pivot_root: overmounts from nullfs BEFORE PIVOT ROOT (nullfs):
>         [   21.185646][ T5251]   [0] ffff88816a4e3c80 (rootfs)
>         [   21.185709][ T5251] VFS: AFTER PIVOT ROOT FROM / to /
>         [   21.192478][ T5251] pivot_root: overmounts from nullfs AFTER PIVOT ROOT (nullfs):
>         [   21.192480][ T5251]   [0] ffff88816a4e2d80 (tmpfs)
>         [   21.201027][ T5251]   [1] ffff88816a4e3c80 (rootfs)
> 
>         <snip>
> 
>         [   29.328721][ T5250] VFS: BEFORE PIVOT ROOT FROM /var/volatile/tmp to /var/volatile/tmp
>         [   29.331584][ T5250] pivot_root: overmounts from nullfs BEFORE PIVOT ROOT (nullfs):
>         [   29.334168][ T5250]   [0] ffff88810ca52300 (rootfs)
>         [   29.335742][ T5250] VFS: AFTER PIVOT ROOT FROM / to /
>         [   29.337399][ T5250] pivot_root: overmounts from nullfs AFTER PIVOT ROOT (nullfs):
>         [   29.339935][ T5250]   [0] ffff88811efba300 (tmpfs)
>         [   29.341133][ T5250]   [1] ffff88810ca52300 (rootfs)
> 
>         <snip>
> 
>         [   30.507784][ T1768] /lkp/lkp/src/monitors/meminfo: line 45: date: not found
>         [   30.507784][ T1768] /lkp/lkp/src/monitors/meminfo: line 46: cat: not found
>         [   30.507784][ T1768] /lkp/lkp/src/monitors/meminfo: line 25: /lkp/lkp/src/bin/event/wait: not found
> 
> During random system call execution
> pivot_root("/var/volatile/tmp", "/var/volatile/tmp")
> is called. This makes the "/var/volatile/tmp" tmpfs mount the rootfs for
> everyone and mounts the old rootfs on top of the new rootfs. That means
> as soon as anything is called that relies on binaries that are located
> in the old rootfs they won't find it anymore as the fs root of all
> tasks has been set to /var/volatile/tmp
> 
> Before nullfs that pivot_root() call would have failed because the
> initramfs mount had no parent mount. nullfs makes that finally work.
> 
> I would like to try and enable nullfs unconditional before we resort to
> making it a boot option. pivot_root() is inherently destructive for a
> test setup so I would just do:
> 
> diff --git a/syscalls/pivot_root.c b/syscalls/pivot_root.c
> index 3a33fcc5..13c00b07 100644
> --- a/syscalls/pivot_root.c
> +++ b/syscalls/pivot_root.c
> @@ -11,4 +11,5 @@ struct syscallentry syscall_pivot_root = {
>         .arg2name = "put_old",
>         .arg2type = ARG_ADDRESS,
>         .group = GROUP_VFS,
> +       .flags = AVOID_SYSCALL, /* May end up switching everyone's rootfs. */
>  };
> 
> You would see the same problem if instead of running from the initramfs
> mount you'd be running from a separate rootfs. In other words running
> these tests with a rootfs would surface the same error.
> 
> I'd appreciate it if you would patch trinity with my diff above (no
> attribution needed). I suspect people generally don't run system call
> fuzzers in their workloads so I'd like to move forward and only revert
> if we have to.

got it. we will test later. but as you mentioned, seems like a corner case,
we will pick this after other tasks with high priorities. thanks!