From: Matthew Wilcox <willy@infradead.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Theodore Tso <tytso@mit.edu>,
Christoph Hellwig <hch@lst.de>,
"Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH] docs: add guidelines for submitting new filesystems
Date: Sat, 18 Apr 2026 22:32:49 +0100 [thread overview]
Message-ID: <aeP4gT5T69izWj-m@casper.infradead.org> (raw)
In-Reply-To: <20260417142503.1436446-1-amir73il@gmail.com>
On Fri, Apr 17, 2026 at 04:25:03PM +0200, Amir Goldstein wrote:
> +Be testable
> + The filesystem must be testable in a meaningful way. The
> + `fstests <https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git>`_
> + framework (also known as xfstests) is the standard testing infrastructure
> + for Linux filesystems and its use is highly recommended. At a minimum,
> + there must be a credible and documented way to test the filesystem and
> + detect regressions. When submitting, include a summary of test results
> + indicating which tests pass, fail, or are not applicable.
Perhaps we need a section on fuzzing? Maybe something like this:
Fuzzing
Filesystems in the Linux kernel are subjected to various fuzzing
activities, by academic researchers, syzbot and malicious actors.
Your filesystem will need to be robust against not just random
syscalls but also fuzzed (corrupted) filesystem images (for block
based filesystems) and crafted hostile network messages (for network
filesystems). It should react appropriately to such attacks,
by repairing or reporting a corrupted filesystem, but not hanging
executing BUG() or WARN() statements or otherwise corrupting the kernel.
Happy for you to reword that.
next prev parent reply other threads:[~2026-04-18 21:32 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 [this message]
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
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=aeP4gT5T69izWj-m@casper.infradead.org \
--to=willy@infradead.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=djwong@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 \
/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