public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Finn Thain <fthain@linux-m68k.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	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@vger.kernel.org,
	debian-ports <debian-ports@lists.debian.org>
Subject: Re: [syzbot] [hfs?] WARNING in hfs_write_inode
Date: Fri, 21 Jul 2023 09:10:09 -0400	[thread overview]
Message-ID: <20230721131009.GE5764@mit.edu> (raw)
In-Reply-To: <3eca2dab-df70-9d91-52a1-af779e3c2e04@linux-m68k.org>

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

  reply	other threads:[~2023-07-21 13:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 14:24 [syzbot] [hfs?] WARNING in hfs_write_inode syzbot
2023-01-04 14:43 ` Arnd Bergmann
2023-01-04 19:06   ` Linus Torvalds
2023-01-04 22:33     ` Arnd Bergmann
2023-01-04 22:42       ` John Paul Adrian Glaubitz
2023-01-05  0:36       ` Viacheslav Dubeyko
2023-01-05  4:37         ` Viacheslav Dubeyko
2023-01-05 15:46           ` Matthew Wilcox
2023-01-05 16:45             ` Viacheslav Dubeyko
2023-07-20 15:27               ` Dmitry Vyukov
2023-07-20 17:30                 ` Matthew Wilcox
2023-07-20 17:50                   ` John Paul Adrian Glaubitz
2023-07-20 17:59                     ` Matthew Wilcox
2023-07-20 18:27                       ` Jeff Layton
2023-07-20 22:20                         ` Dave Chinner
2023-07-21  1:03                           ` Finn Thain
2023-07-21  1:11                             ` Matthew Wilcox
2023-07-21  1:25                               ` Michael Schmitz
2023-07-21  1:45                               ` Finn Thain
2023-07-21  6:42                               ` Kirsten Bromilow
2023-07-21  8:14                               ` Finn Thain
2023-07-21 13:10                                 ` Theodore Ts'o [this message]
2023-07-20 21:38                       ` Jeffrey Walton
2023-07-20 22:37                         ` Matthew Wilcox
2023-07-20 22:53                           ` Linus Torvalds
2023-07-21  1:28                             ` Mike Hosken
2023-07-20 17:56                   ` John Paul Adrian Glaubitz
2023-07-20 19:05                     ` Michael Schmitz
2023-07-21  5:07                       ` John Paul Adrian Glaubitz
2023-07-21  5:40                 ` Eric W. Biederman
2023-01-05 21:34       ` Michael Schmitz
2023-01-05 21:53         ` Linus Torvalds
2023-01-05 23:46           ` Michael Schmitz
2023-01-06  7:09             ` Michael Schmitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230721131009.GE5764@mit.edu \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=christian.brauner@ubuntu.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=david@fromorbit.com \
    --cc=debian-ports@lists.debian.org \
    --cc=dvyukov@google.com \
    --cc=fthain@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=syzbot+7bb7cd3595533513a9e7@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=zhangpeng362@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox