[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230721131009.GE5764@mit.edu>
Date: Fri, 21 Jul 2023 09:10:09 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Matthew Wilcox <willy@...radead.org>,
Dave Chinner <david@...morbit.com>,
Jeff Layton <jlayton@...nel.org>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
Dmitry Vyukov <dvyukov@...gle.com>,
Viacheslav Dubeyko <slava@...eyko.com>,
Arnd Bergmann <arnd@...db.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
syzbot <syzbot+7bb7cd3595533513a9e7@...kaller.appspotmail.com>,
Andrew Morton <akpm@...ux-foundation.org>,
christian.brauner@...ntu.com,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs@...glegroups.com,
ZhangPeng <zhangpeng362@...wei.com>, linux-m68k@...r.kernel.org,
debian-ports <debian-ports@...ts.debian.org>
Subject: Re: [syzbot] [hfs?] WARNING in hfs_write_inode
On Fri, Jul 21, 2023 at 06:14:04PM +1000, Finn Thain wrote:
>
> I'm not blaming the unstable API for the bugs, I'm blaming it for the
> workload. A stable API (like a userspace API) decreases the likelihood
> that overloaded maintainers have to orphan a filesystem implementation.
You are incorrect. The HFS file system has gotten zero development
attention and the bugs were not the result of the API changes. The
main issue here is that the HFS file system does not have maintainer,
and decreasing the workload will not magically make someone appear
with deep knowledge of that particular part of the code base.
It's also the case that the actual amount of work on the "overloaded
maintainers" caused by API changes is minimal --- it's dwarfed by
syzbot noise (complaints from syzbot that aren't really bugs, or for
really outré threat models).
API changes within the kernel are the responsibility of the people
making the change. For example, consider all of the folio changes
that have been landing in the kernel; the amount of extra work on the
part of most file system maintainers is minimal, because it's the
people making the API changes who update the file system. I won't say
that it's _zero_ work, because file system maintainers review the
changes, and we run regression tests, and we sometimes need to point
out when a bug has been introduced --- at which point the person
making the API change has the responsibility of fixing or reverting
the change.
An unstable API are much painful for out-of-tree kernel code. But
upstream kernel developers aren't really concerned with out-of-tree
kernel code, except to point out that the work of the people who are
promulgated out-of-tree modules would be much less if they actually
got them cleaned up and made acceptable for upstream inclusion.
- Ted
Powered by blists - more mailing lists