linux-ext4 - Re: [PATCH 01/33] misc: adapt tests to handle the fuse ext[234] drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxjBpm_2cUDHyU72pSRc5KLDNm9tRgGYsoaAtp6tM6yFwg@mail.gmail.com>
Date: Fri, 7 Nov 2025 08:50:58 +0100
From: Amir Goldstein <amir73il@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: zlang@...hat.com, neal@...pa.dev, fstests@...r.kernel.org, 
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	joannelkoong@...il.com, bernd@...ernd.com
Subject: Re: [PATCH 01/33] misc: adapt tests to handle the fuse ext[234] drivers

On Fri, Nov 7, 2025 at 12:12 AM Darrick J. Wong <djwong@...nel.org> wrote:
>
> On Thu, Nov 06, 2025 at 09:58:28AM +0100, Amir Goldstein wrote:
> > On Wed, Nov 5, 2025 at 11:53 PM Darrick J. Wong <djwong@...nel.org> wrote:
> > >
> > > On Thu, Oct 30, 2025 at 10:51:06AM +0100, Amir Goldstein wrote:
> > > > On Wed, Oct 29, 2025 at 2:22 AM Darrick J. Wong <djwong@...nel.org> wrote:
> > > > >
> > > > > From: Darrick J. Wong <djwong@...nel.org>
> > > > >
> > > > > It would be useful to be able to run fstests against the userspace
> > > > > ext[234] driver program fuse2fs.  A convention (at least on Debian)
> > > > > seems to be to install fuse drivers as /sbin/mount.fuse.XXX so that
> > > > > users can run "mount -t fuse.XXX" to start a fuse driver for a
> > > > > disk-based filesystem type XXX.
> > > > >
> > > > > Therefore, we'll adopt the practice of setting FSTYP=fuse.ext4 to
> > > > > test ext4 with fuse2fs.  Change all the library code as needed to handle
> > > > > this new type alongside all the existing ext[234] checks, which seems a
> > > > > little cleaner than FSTYP=fuse FUSE_SUBTYPE=ext4, which also would
> > > > > require even more treewide cleanups to work properly because most
> > > > > fstests code switches on $FSTYP alone.
> > > > >
> > > >
> > > > I agree that FSTYP=fuse.ext4 is cleaner than
> > > > FSTYP=fuse FUSE_SUBTYPE=ext4
> > > > but it is not extendable to future (e.g. fuse.xfs)
> > > > and it is still a bit ugly.
> > > >
> > > > Consider:
> > > > FSTYP=fuse.ext4
> > > > MKFSTYP=ext4
> > > >
> > > > I think this is the correct abstraction -
> > > > fuse2fs/ext4 are formatted that same and mounted differently
> > > >
> > > > See how some of your patch looks nicer and naturally extends to
> > > > the imaginary fuse.xfs...
> > >
> > > Maybe I'd rather do it the other way around for fuse4fs:
> > >
> > > FSTYP=ext4
> > > MOUNT_FSTYP=fuse.ext4
> > >
> >
> > Sounds good. Will need to see the final patch.
> >
> > > (obviously, MOUNT_FSTYP=$FSTYP if the test runner hasn't overridden it)
> > >
> > > Where $MOUNT_FSTYP is what you pass to mount -t and what you'd see in
> > > /proc/mounts.  The only weirdness with that is that some of the helpers
> > > will end up with code like:
> > >
> > >         case $FSTYP in
> > >         ext4)
> > >                 # do ext4 stuff
> > >                 ;;
> > >         esac
> > >
> > >         case $MOUNT_FSTYP in
> > >         fuse.ext4)
> > >                 # do fuse4fs stuff that overrides ext4
> > >                 ;;
> > >         esac
> > >
> > > which would be a little weird.
> > >
> >
> > Sounds weird, but there is always going to be weirdness
> > somewhere - need to pick the least weird result or most
> > easy to understand code IMO.
> >
> > > _scratch_mount would end up with:
> > >
> > >         $MOUNT_PROG -t $MOUNT_FSTYP ...
> > >
> > > and detecting it would be
> > >
> > >         grep -q -w $MOUNT_FSTYP /proc/mounts || _fail "booooo"
> > >
> > > Hrm?
> >
> > Those look obviously nice.
> >
> > Maybe the answer is to have all MOUNT_FSTYP, MKFS_FSTYP
> > and FSTYP and use whichever best fits in the context.
>
> Hrmm well I would /like/ avoid adding MKFS_FSTYP since ext4 is ext4, no
> matter whether we're using the kernel or fuse42fs.  Do you have a use
> case for adding such a thing?
>

No use case, beyond more flexibility in writing clear code.
I agree with Zorro that ext4 is not only ext4.
ext4 is ext4 on-disk format and it is ext4 driver and this ambiguity
can be a source of confusion sometimes.

I don't see the problem with defining MKFS_FSTYP
the controversial part IMO is what FSTYP should be
referring to, the flesh or the spirit...

Trying to think up a use case, ntfs has at least 3 Linux drivers
that I know of (ntfs,ntfs3 and fuse.ntfs-3g) and another one that was recently
proposed (ntfsplus). At least some have also their matching mkfs
and should be able to cross mount an ntfs formatted by other mkfs.

So testing any variation of MKFS_FSTYP and MOUNT_FSTYP
makes sense.

Using MKFS_FSTYP in mkfs and fsck helpers and using MOUNT_FSTYP
in mount helpers is always good practice IMO.

My intuition is that FSTYP should be defined to whichever
results in less churn and less weird looking code, but I don't know
which one that would be.

Thanks,
Amir.