Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Christian Brauner <brauner@kernel.org>]

On Thu, Sep 07, 2023 at 05:57:47AM -0700, Guenter Roeck wrote:
> On 9/7/23 04:18, Thorsten Leemhuis wrote:
> > On 07.09.23 12:29, Christian Brauner wrote:
> > > > So why can't that work similarly for unmaintained file systems? We could
> > > > even establish the rule that Linus should only apply patches to some
> > > > parts of the kernel if the test suite for unmaintained file systems
> > > > succeeded without regressions. And only accept new file system code if a
> > > 
> > > Reading this mail scared me.
> > 
> > Sorry about that, I can fully understand that. It's just that some
> > statements in this thread sounded a whole lot like "filesystems want to
> > opt-out of the no regression rule" to me. That's why I at some point
> > thought I had to speak up.
> > 
> > > The list of reiserfs bugs alone is crazy.
> > 
> > Well, we regularly remove drivers or even support for whole archs
> > without getting into conflict with the "no regressions" rule, so I'd say
> > that should be possible for file systems as well.
> > 
> > And I think for reiserfs we are on track with that.
> > 
> > But what about hfsplus? From hch's initial mail of this thread it sounds
> > like that is something users would miss. So removing it without a very
> > strong need[1] seems wrong to me. That's why I got involved in this
> > discussion.
> > 
> 
> The original mail also suggested that there would be essentially no means
> to create a hfsplus file system in Linux. That would mean it would, for all
> practical purposes, be untestable.
> 
> However:
> 
> $ sudo apt-get install hfsprogs
> $ truncate -s 64M filesystem.hfsplus
> $ mkfs.hfsplus filesystem.hfsplus
> Initialized filesystem.hfsplus as a 64 MB HFS Plus volume
> $ file filesystem.hfsplus
> filesystem.hfsplus: Macintosh HFS Extended version 4 data last mounted by: '10.0', created: Thu Sep  7 05:41:21 2023, last modified: Thu Sep  7 12:41:21 2023, last checked: Thu Sep  7 12:41:7
> 
> So I am not really sure I understand what the problem actually is.
> 
> No a side note, the crash I observed with ntfs3 was introduced by
> commit a4f64a300a29 ("ntfs3: free the sbi in ->kill_sb").

I just gave you a fix to test for your report.

(ntfs3 was holding on to inodes past ->put_super(). Anyway, not relevant
for this discussion here.)