[LTP] next-20250915: LTP chdir01 df01_sh stat04 tst_device.c:97: TBROK: Could not stat loop device 0

[Naresh Kamboju]

On Tue, 16 Sept 2025 at 17:04, Jan Kara <jack@suse.cz> wrote:
>
> On Tue 16-09-25 13:04:42, Jan Kara wrote:
> > On Tue 16-09-25 12:57:26, Naresh Kamboju wrote:
> > > The following LTP chdir01 df01_sh and stat04 tests failed on the rock-pi-4b
> > > qemu-arm64 on the Linux next-20250915 tag build.
> > >
> > > First seen on next-20250915
> > > Good: next-20250912
> > > Bad: next-20250915
> > >
> > > Regression Analysis:
> > > - New regression? yes
> > > - Reproducibility? yes
> > >
> > > * rk3399-rock-pi-4b, ltp-smoke
> > > * qemu-arm64, ltp-smoke
> > > * qemu-arm64-compat, ltp-smoke
> > >  - chdir01
> > >   - df01_sh
> > >   - stat04
> > >
> > > Test regression: next-20250915: LTP chdir01 df01_sh stat04
> > > tst_device.c:97: TBROK: Could not stat loop device 0
> >
> > This is really strange. Those failing tests all start to complain that
> > /dev/loop0 doesn't exist (open gets ENOENT)... The fact that this is
> > limited to only a few archs suggests it's some race somewhere but I don't
> > see any relevant changes in linux-block in last three days...
>
> Ha, Mark Brown tracked this [1] to changes in VFS tree in
> extensible_ioctl_valid(). More discussion there I guess.

That right,
Ander’s bisection confirmed the same commit that Mark Brown reported.

# first bad commit:
 [60949057a2e71c9244e82608adf269e62e6ac443]
block: use extensible_ioctl_valid()

>
> [1] https://lore.kernel.org/all/02da33e3-6583-4344-892f-a9784b9c5b1b@sirena.org.uk
>
>                                                                 Honza
>
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

- Naresh