Re: BUG: unable to handle kernel paging request in do_mount

From: Dmitry Vyukov <dvyukov@google.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Dmitry Vyukov <dvyukov@google.com>,
	syzbot <syzbot+73c7fe4f77776505299b@syzkaller.appspotmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	sabin.rapan@gmail.com,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: BUG: unable to handle kernel paging request in do_mount
Date: Mon, 20 May 2019 18:22:05 +0200	[thread overview]
Message-ID: <CACT4Y+Z8gfJC1a9_WMPRE4Z+qF2wfANkkXCqD3D7YFbkES8XPQ@mail.gmail.com> (raw)
In-Reply-To: <20190518201843.GD14277@mit.edu>

On Sat, May 18, 2019 at 10:19 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Sat, May 18, 2019 at 05:21:42PM +0100, Al Viro wrote:
> > IOW, Dan's fix folded into the offending commit.  And that kind of
> > pattern is not rare; I would argue that appending Dan's patch at
> > the end of queue and leaving the crap in between would be a fucking
> > bad idea - it would've left a massive bisection hazard *and* made
> > life much more unpleasant when the things got to merging into the
> > mainline (or reviewing, for that matter).
>
> When this happens in the ext4 git tree, I usually don't worry about
> giving credit to whatever system finds the problem, whether coming
> from it's Coverity, or someone running sparse, or syzbot, etc.
>
> There will always be issues where there are no way to clear out the
> syzbot report via a commit description --- for example, when a patch
> gets dropped entirely from linux-next.  With Coverity, the report gets
> dropped automatically.  With syzbot, it will have closed out by hand.
>
> > What would you prefer to happen in such situations?  Commit summaries
> > modified enough to confuse CI tools into *NOT* noticing that those
> > are versions of the same patch?  Some kind of metadata telling the
> > same tools that such-and-such commits got folded in (and they might
> > have been split in process, with parts folded into different spots
> > in the series, at that)?
> >
> > Because "never fold in, never reorder, just accumulate patches in
> > the end of the series" is not going to fly.  For a lot of reasons.
>
> As far as I'm concerned, this is the tools problem; I don't think it's
> worth it for developers to feel they need to twist themselves into
> knots just to try to make the CI tools' life easier.
>
>                                         - Ted

I've added docs re linux-next handling:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#linux-next
In the end it's still just adding a tag. And it's not so much about
crediting or making somebody's life easier, this is mainly about
making Linux less buggy and higher-quality.