linux-ext4 - Re: [PATCH] fuse2fs: reopen filesystem read-write for read-only journal recovery

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: <20251015214028.GE6170@frogsfrogsfrogs>
Date: Wed, 15 Oct 2025 14:40:28 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Dave Dykstra <dwd@...n.ch>
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCH] fuse2fs: reopen filesystem read-write for read-only
 journal recovery

On Wed, Oct 15, 2025 at 10:33:40AM -0500, Dave Dykstra wrote:
> On Tue, Oct 14, 2025 at 06:15:05PM -0700, Darrick J. Wong wrote:
> > On Fri, Oct 10, 2025 at 04:47:35PM -0500, Dave Dykstra wrote:
> > > This changes the strategy added in c7f2688540d95e7f2cbcd178f8ff62ebe079faf7
> > > for recovery of journals when read-only is requested.
> ...
> > ro and EXT2_FLAG_RW are not the same thing!
> 
> I understand that.
> 
> ...
> > I don't like this, because we should open the filesystem with
> > EXT2_FLAG_RW set by default and only downgrade to !EXT2_FLAG_RW if we
> > can't open it...
> 
> I was following the suggestion of tytso at
>     https://github.com/tytso/e2fsprogs/issues/244#issuecomment-3390084495
> 
> However, I think your suggestion might be better.  I will try that.

Urrrrrgh, external conversations that need to be on the mailing list.
Already covered here:
https://lore.kernel.org/linux-ext4/175798064776.350013.6744611652039454651.stgit@frogsfrogsfrogs/

> ...
> 
> > ...if the close fails, you just leaked the old global_fs context.
> > ext2fs_close_free is what you want (and yes that's a bug in fuse2fs).
> 
> Ok, thanks, I'll use that.
> 
> ...
> > ...and also, if you re-do ext2fs_open2(), you then have to re-check all
> > the feature support bits above because we unlocked the filesystem
> > device, which means its contents could have been replaced completely
> > in the interim.
> 
> I'm not convinced that's something to worry about, but in any case
> your suggestion of only opening ro if rw fails should avoid it.

...and then in the pile of patches I break up all the stuff in main() so
that there's one fuse2fs_open() routine, after which the fs context
doesn't change and the fd stays open:
https://lore.kernel.org/linux-ext4/175798064597.349841.13113367506205034632.stgit@frogsfrogsfrogs/

> > Also note that I have a /very large/ pile of fuse2fs improvements and
> > rewrites and cleanups that are out for review on the list; you might
> > want to look at those first.
> 
> I do appreciate your efforts.  Unfortunately I have too many other
> priorities to have enough bandwidth to take on general responsibility
> for reviewing fuse2fs patches.  I also don't have much experience with
> filesystems.  I'm only trying to help here because it is impacting a

This exact mentality is why filesystem development has become very
frustrating...

> case that I support.  I was very happy when I found that the fuse2fs in
> v1.47.3 of e2fsprogs fixed another user-reported problem, but the new
> version ended up causing a couple of new problems.

...though I'm not blaming you (or any other user for that matter),
just venting about the development community. :(

Are there other problems I should know about?

> Having said that, if there are particular patches that you think are
> important bug fixes that you would like to call my attention to, please
> send me a direct message. I could test them and respond.

They're all just waiting for Ted to put out the last 1.47.x release and
open up 1.48 development.

--D

> Dave
>