Re: Bug: INFO_ task hung in lock_two_nondirectories

["Darrick J. Wong" <djwong@kernel.org>]

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!  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