Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i58a146ae:Fastmail
Date:   Fri, 21 Jul 2023 11:45:39 +1000 (AEST)
From:   Finn Thain <fthain@linux-m68k.org>
To:     Matthew Wilcox <willy@infradead.org>
cc:     Dave Chinner <david@fromorbit.com>,
        Jeff Layton <jlayton@kernel.org>,
        John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
        Dmitry Vyukov <dvyukov@google.com>,
        Viacheslav Dubeyko <slava@dubeyko.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        syzbot <syzbot+7bb7cd3595533513a9e7@syzkaller.appspotmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        christian.brauner@ubuntu.com,
        Damien Le Moal <damien.lemoal@opensource.wdc.com>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller-bugs@googlegroups.com,
        ZhangPeng <zhangpeng362@huawei.com>,
        linux-m68k@lists.linux-m68k.org,
        debian-ports <debian-ports@lists.debian.org>
Subject: Re: [syzbot] [hfs?] WARNING in hfs_write_inode
In-Reply-To: <ZLnbN4Mm9L5wCzOK@casper.infradead.org>
Message-ID: <23b19f18-13a3-1744-cdce-801cfa35a807@linux-m68k.org>
References: <46F233BB-E587-4F2B-AA62-898EB46C9DCE@dubeyko.com> <Y7bw7X1Y5KtmPF5s@casper.infradead.org> <50D6A66B-D994-48F4-9EBA-360E57A37BBE@dubeyko.com> <CACT4Y+aJb4u+KPAF7629YDb2tB2geZrQm5sFR3M+r2P1rgicwQ@mail.gmail.com> <ZLlvII/jMPTT32ef@casper.infradead.org>
 <2d0bd58fb757e7771d13f82050a546ec5f7be8de.camel@physik.fu-berlin.de> <ZLl2Fq35Ya0cNbIm@casper.infradead.org> <868611d7f222a19127783cc8d5f2af2e42ee24e4.camel@kernel.org> <ZLmzSEV6Wk+oRVoL@dread.disaster.area> <60b57ae9-ff49-de1d-d40d-172c9e6d43d5@linux-m68k.org>
 <ZLnbN4Mm9L5wCzOK@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Fri, 21 Jul 2023, Matthew Wilcox wrote:

> On Fri, Jul 21, 2023 at 11:03:28AM +1000, Finn Thain wrote:
> > On Fri, 21 Jul 2023, Dave Chinner wrote:
> > 
> > > > I suspect that this is one of those catch-22 situations: distros 
> > > > are going to enable every feature under the sun. That doesn't mean 
> > > > that anyone is actually _using_ them these days.
> > 
> > I think the value of filesystem code is not just a question of how 
> > often it gets executed -- it's also about retaining access to the data 
> > collected in archives, museums, galleries etc. that is inevitably held 
> > in old formats.
> 
> That's an argument for adding support to tar, not for maintaining 
> read/write support.
> 

I rather think it's an argument for collaboration between the interested 
parties upstream (inluding tar developers). As I see it, the question is, 
what kind of "upstream" is best for that?

> > > We need to much more proactive about dropping support for 
> > > unmaintained filesystems that nobody is ever fixing despite the 
> > > constant stream of corruption- and deadlock- related bugs reported 
> > > against them.
> > 
> > IMO, a stream of bug reports is not a reason to remove code (it's a 
> > reason to revert some commits).
> > 
> > Anyway, that stream of bugs presumably flows from the unstable kernel 
> > API, which is inherently high-maintenance. It seems that a stable API 
> > could be more appropriate for any filesystem for which the on-disk 
> > format is fixed (by old media, by unmaintained FLOSS implementations 
> > or abandoned proprietary implementations).
> 
> You've misunderstood.  Google have decided to subject the entire kernel 
> (including obsolete unmaintained filesystems) to stress tests that it's 
> never had before.  IOW these bugs have been there since the code was 
> merged.  There's nothing to back out.  There's no API change to blame. 
> It's always been buggy and it's never mattered before.
> 

I see. Thanks for providing that background.

> It wouldn't be so bad if Google had also decided to fund people to fix 
> those bugs, but no, they've decided to dump them on public mailing lists 
> and berate developers into fixing them.
> 

Those bugs, if moved from kernel to userspace, would be less harmful, 
right?