linux-ext4 - Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aPgKP-wUhhfwqKke@cern.ch>
Date: Tue, 21 Oct 2025 17:33:35 -0500
From: Dave Dykstra <dwd@...n.ch>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCH] fuse2fs: updates for message reporting journal is not
 supported

On Fri, Oct 17, 2025 at 04:25:21PM -0700, Darrick J. Wong wrote:
> On Fri, Oct 17, 2025 at 03:09:57PM -0500, Dave Dykstra wrote:
> > On Fri, Oct 17, 2025 at 12:18:00PM -0700, Darrick J. Wong wrote:
...
> > > > -	if (global_fs->flags & EXT2_FLAG_RW) {
> > > > +	if (!fctx.ro) {
> > > 
> > > Again, rw != EXT2_FLAG_RW.
> > > 
> > > The ro and rw mount options specify if the filesystem mount is writable.
> > > You can mount a filesystem in multiple places, and some of the mounts
> > > can be ro and some can be rw.
> > > 
> > > EXT2_FLAG_RW specifies that the filesystem driver can write to the block
> > > device.  fuse2fs should warn about incomplete journal support any time
> > > the **filesystem** is writable, independent of the write state of the
> > > mount.
> > 
> > Are you saying that is indeed possible for a read-only mount to cause
> > file corruption or data loss if there's not a graceful unmount?  If so,
> 
> No, I'm saying that filesystem drivers can *themselves* write metadata
> to a filesystem mounted ro.  ro means that user programs can't write to
> the files under a particular mountpoint.  This has long been the case
> for the kernel implementations of ext*, XFS, btrfs, etc.

I understood that, but does the filesystem actually write metadata after
the journal is recovered, such that if the fuse2fs process dies without
a clean unmount there might be file corruption or data loss?  That is,
in the case of ro when there is write access, does the warning message
really apply?

> I've said this three times now, and this is the last time I'm going to
> say it.

I understood what you said but I'm asking about the implications.

...
> Are you running fstests QA on these patches before you send them out?

I had not heard of them, and do not see them documented anywhere in
e2fsprogs, so I don't know how I was supposed to have known they were
needed.  Ideally there would be an automated CI test suite.  The patches
have passed the github CI checks (which don't show up in the standard
pull request place, but I found them in my own repo's Actions tab).

Are you talking about the tests at https://github.com/btrfs/fstests?
If so, it looks like there are a ton of options.  Is there a standard
way to run them with fuse2fs?

Dave