Message-ID: <CACT4Y+YVy3OqiG=HD4TcERCHqS7XrNUwMgJtjM-HLC_-kA5rdw@mail.gmail.com>
Date: Tue, 14 Jan 2025 10:15:28 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Matthew Wilcox <willy@...radead.org>, Christian Brauner <brauner@...nel.org>, 
	Kun Hu <huk23@...udan.edu.cn>, Andrey Konovalov <andreyknvl@...il.com>, jack@...e.cz, 
	jlayton@...hat.com, tytso@....edu, adilger.kernel@...ger.ca, 
	david@...morbit.com, bfields@...hat.com, viro@...iv.linux.org.uk, 
	christian.brauner@...ntu.com, hch@....de, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: Bug: INFO_ task hung in lock_two_nondirectories

On Mon, 13 Jan 2025 at 19:08, Darrick J. Wong <djwong@...nel.org> wrote:
>
> On Mon, Jan 13, 2025 at 04:19:01PM +0000, Matthew Wilcox wrote:
> > On Mon, Jan 13, 2025 at 03:38:57PM +0100, Christian Brauner wrote:
> > > On Sun, Jan 12, 2025 at 06:00:24PM +0800, Kun Hu wrote:
> > > > Hello,
> > > >
> > > > When using our customized fuzzer tool to fuzz the latest Linux kernel, the following crash (43s)
> > > > was triggered.
> > >
> > > I think we need to come to an agreement at LSFMM or somewhere else that
> > > we will by default ingore but reports from non-syzbot fuzzers. Because
> > > we're all wasting time on them.
>
> No need to wait until LSFMM, I already agree with the premise of
> deprioritizing/ignoring piles of reports that come in all at once with
> very little analysis, an IOCCC-esque reproducer, and no effort on the
> part of the reporter to do *anything* about the bug.
>
> While the Google syzbot dashboard has improved remarkably since 2018,
> particularly in the past couple of years, thanks to the people who did
> that!

And, thanks, Darrick!
Most credit goes to Aleksandr Nogikh, who worked on improvements in
the past years.
We don't always have cycles to implement everything immediately, but
we are listening.

>  It's nice that I can fire off patches at the bot and it'll test
> them.  That said, I don't perceive Google management to be funding much
> of anyone to solve the problems that their fuzzer uncovers.
>
> This is to say nothing of the people who are coyly running their own
> instances of syzbot sans dashboard and expecting me to download random
> crap from Google Drive.  Hell no, I don't do that kind of thing in 2025.
>
> > I think it needs to be broader than that to also include "AI generated
> > bug reports" (while not excluding AI-translated bug reports); see
> >
> > https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/
> >
> > so really, any "automated bug report" system is out of bounds unless
> > previously arranged with the developers who it's supposed to be helping.
>
> Agree.  That's been my stance since syzbot first emerged in 2017-18.
>
> > We need to write that down somewhere in Documentation/process/ so we
> > can point misguided people at it.
> >
> > We should also talk about how some parts of the kernel are basically
> > unmaintained and unused, and that automated testing should be focused
> > on parts of the kernel that are actually used.  A report about being
> > able to crash a stock configuration of ext4 is more useful than being
> > able to crash an unusual configuration of ufs.
>
> Or maybe we should try to make fuse + iouring fast enough that we can
> kick all these old legacy drivers out to userspace. ;)
>
> > Distinguishing between warnings, BUG()s and actual crashes would also
> > be a useful thing to put in this document.
>
> Yes.  And also state that panic_on_warn=1 is a signal that you wanted
> fail(over) fast mode.
>
> --D

Powered by blists - more mailing lists