linux-kernel - Re: Bug: INFO_ task hung in lock_two

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z4U89Wfyaz2fLbCt@casper.infradead.org>
Date: Mon, 13 Jan 2025 16:19:01 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Kun Hu <huk23@...udan.edu.cn>, Andrey Konovalov <andreyknvl@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.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, 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.

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

Distinguishing between warnings, BUG()s and actual crashes would also
be a useful thing to put in this document.