From: "Darrick J. Wong" <djwong@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Amir Goldstein <amir73il@gmail.com>,
Christian Brauner <brauner@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Theodore Tso <tytso@mit.edu>,
Christoph Hellwig <hch@lst.de>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH] docs: add guidelines for submitting new filesystems
Date: Tue, 21 Apr 2026 11:10:26 -0700 [thread overview]
Message-ID: <20260421181026.GG7765@frogsfrogsfrogs> (raw)
In-Reply-To: <fe5uzacwrsuabvxp7xrsz3biiellrebtbmkoeus57xottgp5c7@wssdohk22lvr>
On Tue, Apr 21, 2026 at 02:08:13PM +0200, Jan Kara wrote:
> On Tue 21-04-26 13:17:34, Amir Goldstein wrote:
> > On Tue, Apr 21, 2026 at 12:16 PM Jan Kara <jack@suse.cz> wrote:
> > > I definitely want to keep a clause like this. Maybe I'd just reformulate it
> > > like:
> > >
> > > - Handle security issues promptly. Both those reported by ordinary users
> > > as well as those reported by fuzzing tools. Expect that your filesystem
> > > will be subject to syscall fuzzing as well as filesystem image fuzzing.
> > > Dealing with maliciously corrupted filesystem images is not generally
> > > considered a high severity security issue but still it is considered a
> > > quality-of-implementation issue that should be fixed.
> > >
> >
> > I can take this version, but tbh feels like debating this clause misses
> > the main goal of the doc, so I'd rather go with something a lot shorter:
> >
> > - Handle security issues and regression promptly. Both those reported
> > by ordinary users as well as those reported by test bots.
> >
> > IMO, getting into more details doesn't really add much value to the
> > prospect reader of the doc before submitting a new filesystem nor to
> > the filesystem reviewer.
>
> Agreed. Your shorter version conveys the idea and the details aren't that
> useful. So the short version is fine.
I still want
"The filesystem must handle corrupted input gracefully without hanging
or crashing the kernel."
to be part of this. Not screwing over a running system is important,
The guidelines ought to make that explicit.
--D
>
> Honza
>
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
next prev parent reply other threads:[~2026-04-21 18:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 14:25 [PATCH] docs: add guidelines for submitting new filesystems Amir Goldstein
2026-04-17 15:36 ` Matthew Wilcox
2026-04-17 16:44 ` Amir Goldstein
2026-04-17 17:20 ` Jaegeuk Kim
2026-04-18 17:24 ` Amir Goldstein
2026-04-18 22:18 ` Jaegeuk Kim
2026-04-19 11:06 ` Amir Goldstein
2026-04-18 21:32 ` Matthew Wilcox
2026-04-19 11:03 ` Amir Goldstein
2026-04-20 8:15 ` Jan Kara
2026-04-20 8:32 ` Jan Kara
2026-04-20 18:14 ` Amir Goldstein
2026-04-20 18:34 ` Darrick J. Wong
2026-04-21 10:16 ` Jan Kara
2026-04-21 11:17 ` Amir Goldstein
2026-04-21 12:08 ` Jan Kara
2026-04-21 18:10 ` Darrick J. Wong [this message]
2026-04-21 19:42 ` Amir Goldstein
2026-04-21 20:15 ` Darrick J. Wong
2026-04-21 20:22 ` Amir Goldstein
2026-04-22 14:09 ` Theodore Tso
2026-04-22 14:35 ` Amir Goldstein
2026-04-22 15:50 ` Darrick J. Wong
2026-04-21 11:27 ` Christian Brauner
2026-04-21 11:45 ` Amir Goldstein
2026-04-22 8:50 ` Askar Safin
2026-04-22 9:02 ` Amir Goldstein
2026-04-22 12:35 ` Christian Brauner
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=20260421181026.GG7765@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.