All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, 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 13:15:02 -0700	[thread overview]
Message-ID: <20260421201502.GH7765@frogsfrogsfrogs> (raw)
In-Reply-To: <CAOQ4uxhq4J+t+6-qhGOoaZn0Fdh9Q05RkX-CRYm+huJSPUJHjw@mail.gmail.com>

On Tue, Apr 21, 2026 at 09:42:23PM +0200, Amir Goldstein wrote:
> On Tue, Apr 21, 2026 at 8:10 PM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > 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.
> 
> Agree.
> 
>  - Handle security issues and regression promptly.  Both those reported
>    by ordinary users and those reported by test bots and fuzzing tools.
>    The filesystem must handle corrupted input gracefully without hanging
>    or crashing the kernel.

How about
"...without corrupting memory, hanging, or crashing the kernel."

--D

> 
> Thanks,
> Amir.

  reply	other threads:[~2026-04-21 20:15 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
2026-04-21 19:42             ` Amir Goldstein
2026-04-21 20:15               ` Darrick J. Wong [this message]
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=20260421201502.GH7765@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.