linux-kernel - Re: Bug: task hung in shmem_swapin

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] [day] [month] [year] [list]

Message-ID: <Z4SfPEeheA_Fd5pD@casper.infradead.org>
Date: Mon, 13 Jan 2025 05:06:04 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Kun Hu <huk23@...udan.edu.cn>
Cc: hch@....de, jlayton@...nel.org, kirill.shutemov@...ux.intel.com,
	vbabka@...e.cz, william.kucharski@...cle.com, rppt@...ux.ibm.com,
	dhowells@...hat.com, akpm@...ux-foundation.org, hughd@...gle.com,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: Bug: task hung in shmem_swapin_folio

On Sun, Jan 12, 2025 at 08:51:20PM +0800, Kun Hu wrote:
> > 2025年1月12日 20:02，Matthew Wilcox <willy@...radead.org> 写道：
> > 
> > On Sun, Jan 12, 2025 at 05:46:24PM +0800, Kun Hu wrote:
> >> Hello,
> >> 
> >> When using our customized fuzzer tool to fuzz the latest Linux kernel, the following crash (42s)
> >> was triggered.
> > 
> > It's not a crash.  It's a warning.  You've just configured your kernel
> > to crash when emitting a warning.
> > 
> > What you need to do is poke around in the reproducer you've found and
> > figure out what it is you're doing that causes this warning.  Are
> > you constraining your task with memory groups, for example?  Are you
> > doing a huge amount of I/O which is causing your disk to be
> > bottlenecked?  Something else?
> > 
> > It's all very well to automate finding bugs, but you're asking other
> > people to do a lot of the work for you.
> > 
> 
> Thank you very much and sorry at the same time.
> 
> We know that most of the work of locating a issue should be done by the reporter, but having just looked into fuzzing against the kernel, the background knowledge of the kernel is not very familiar at the moment. That's why we've taken the approach of sending out a report first, and after getting professional feedback from the maintainers, we're able to target test a particular subsystem or module for them to improve efficiency.
> 
> Our strategy seems to be incorrect and certainly due to our lack of Kernel expertise, again I apologize, we will improve and hopefully report really useful information.

I'm not asking you to analyse the kernel; that is indeed a hard task.
I'm asking you to analyse the reproducer.  What is it really doing to
create the problem?  Often syzkaller includes a lot of extraneous goop
that's not relevant.  So, you can try to minimise the reproducer.

If you're going to be fuzzing filesystems (and it seems like you've
sent a lot of filesystem reports), then you should probably say if the
reproducer uses a specially crafted image.  Most filesystem developers
will prioritise these bugs differently.

It's really hard to get a good workflow going with syzkaller.  Google
has been trained now, and syzbot mostly produces good quality bugs.
It's really frustrating to have to train a new group of people all
over again.  It would be much better if you worked with Google to get
your changes into syzbot.  Probably less work for you, too.