linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Jan Kara <jack@suse.cz>, Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>, Ted Tso <tytso@mit.edu>,
	yebin <yebin@huaweicloud.com>,
	linux-fsdevel@vger.kernel.org, Kees Cook <keescook@google.com>,
	Alexander Popov <alex.popov@linux.com>,
	syzkaller <syzkaller@googlegroups.com>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH] block: Add config option to not allow writing to mounted devices
Date: Wed, 14 Jun 2023 10:26:30 +1000	[thread overview]
Message-ID: <ZIkJNmpO/S7pv0A6@dread.disaster.area> (raw)
In-Reply-To: <CACT4Y+aEScXmq2F1-vqAfr-b2w-xyOohN+FZxorW1YuRvKDLNQ@mail.gmail.com>

On Tue, Jun 13, 2023 at 08:49:38AM +0200, Dmitry Vyukov wrote:
> On Mon, 12 Jun 2023 at 18:16, Jan Kara <jack@suse.cz> wrote:
> >
> > Writing to mounted devices is dangerous and can lead to filesystem
> > corruption as well as crashes. Furthermore syzbot comes with more and
> > more involved examples how to corrupt block device under a mounted
> > filesystem leading to kernel crashes and reports we can do nothing
> > about. Add config option to disallow writing to mounted (exclusively
> > open) block devices. Syzbot can use this option to avoid uninteresting
> > crashes. Also users whose userspace setup does not need writing to
> > mounted block devices can set this config option for hardening.
> 
> +syzkaller, Kees, Alexander, Eric
> 
> We can enable this on syzbot, however I have the same concerns as with
> disabling of XFS_SUPPORT_V4:
> https://github.com/google/syzkaller/issues/3918#issuecomment-1560624278

Really?

This is exactly what I *detest most* about syzbot: the recalcitrant
maintainer who thinks their ideology is more important than any
other engineering consideration that might exist.

We want *better quality bug reports* on *current code* that we have
to *support for the foreseeable future*, not get buried under
repeated shitty reports containing yet more variants of problems we
fixed over a decade ago.

I'll repeat what Eric has already pointed out in the above GH issue
in the vain hope you'll listen this time rather than making even more
extreme ideological demands on us.

The XFS engineers put in place a planned, well documented
deprecation and removal process for V4 format support back in 2020.
We are well into that plan - we are not that far from turning it off
v4 support by default. The V4 format is legacy code and users are
already migrating away from it.

As such, it has much lower priority and relevance to us compared to
supporting v5 filesystems. The syzbot maintainers don't get to
decide how important XFS v4 format support is - that's the job of
the XFS engineers responsibile for developing XFS code and
supporting XFS users.

Because V4 has been deprecated and support is slowing down as people
migrate off it, we don't need as extensive test coverage as we once
did. i.e.  we are ramping down the validation in accordance with
it's lower priority and approaching disabling in 2025. We are
placing much more importance on validation of v5 format features and
functionality.

As such, we really don't need syzbot to be exercising v4 formats any
more - it's much more important to our users that we exercise v5
formats as extensively as possible. That is what we are asking the
syzkaller runners (and syzbot) do as a service for us.

If your ideology demands that "the only way to stop syzbot testing
XFS v4 filesytsems is to remove the code entirely" (paraphrasing
your comments from the above github issue), then the entire problem
here is your ideology.

That is, your ideology is getting in the way of practical, well
thought out, long running end-of-life engineering processes. It is
creating unnecessary load on limited resources. Further, your
demands that we place syzbot coverage (if syzbot doesn't test it, it
must depend on CONFIG_INSECURE!) above our direct responsibilities
to distro maintainers and other downstream users is, at best,
terribly misguided.

Syzbot is a *tool*. It's not even a critical tool we depend on - we
can live without it just fine. We'd really like syzbot to be a
better tool, but the ideology behind syzbot is the biggest
impediment to making it a better, more effective tool for the
community.

If syzbot maintainers won't listen to simple requests to improve
test coverage according to subsystem requirements, then it's clear
that syzbot is being driven by ideology rather than engineering
requirements. This needs to change.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2023-06-14  0:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 16:16 [PATCH] block: Add config option to not allow writing to mounted devices Jan Kara
2023-06-12 16:25 ` Jan Kara
2023-06-12 17:39   ` Bart Van Assche
2023-06-12 17:47     ` Theodore Ts'o
2023-06-12 18:52     ` Colin Walters
2023-06-13 11:34       ` Jan Kara
2023-06-14  1:55         ` Darrick J. Wong
2023-06-14  7:14           ` Christoph Hellwig
2023-06-14  7:05         ` Christian Brauner
2023-06-14  7:07           ` Christoph Hellwig
2023-06-14  7:10         ` Christoph Hellwig
2023-06-14 10:12           ` Jan Kara
2023-06-14 14:30             ` Christoph Hellwig
2023-06-14 14:46             ` Matthew Wilcox
2023-06-13  4:56 ` kernel test robot
2023-06-13  5:10 ` Christoph Hellwig
2023-06-13  6:09   ` Dmitry Vyukov
2023-06-14  7:17     ` Christoph Hellwig
2023-06-14  8:18       ` Christian Brauner
2023-06-14 10:36         ` Jan Kara
2023-06-14 12:48           ` Christian Brauner
2023-06-15 14:39             ` Jan Kara
2023-06-14 14:31         ` Christoph Hellwig
2023-06-13 20:56   ` Jan Kara
2023-06-14  7:20     ` Christoph Hellwig
2023-06-20 10:41       ` Jan Kara
2023-06-20 11:29         ` Christoph Hellwig
2023-06-14  7:35     ` Christian Brauner
2023-06-13  6:49 ` Dmitry Vyukov
2023-06-13 19:22   ` Theodore Ts'o
2023-06-14  0:26   ` Dave Chinner [this message]
2023-06-14  2:04   ` Darrick J. Wong
2023-06-14  2:57     ` Theodore Ts'o
2023-06-14 12:27     ` Dmitry Vyukov
2023-06-14 23:38       ` Dave Chinner
2023-06-15  9:14         ` Dmitry Vyukov
2023-06-18 23:35           ` Dave Chinner

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=ZIkJNmpO/S7pv0A6@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=alex.popov@linux.com \
    --cc=axboe@kernel.dk \
    --cc=dvyukov@google.com \
    --cc=ebiggers@google.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=keescook@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=tytso@mit.edu \
    --cc=yebin@huaweicloud.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;
as well as URLs for NNTP newsgroup(s).