On 5/24/23 9:59 PM, Pengfei Xu wrote:
Hi Dave, Greeting! Platform: Alder lake There is "soft lockup in __cleanup_mnt" in v6.4-rc3 kernel. Syzkaller analysis repro.report and bisect detailed info: https://github.com/xupengfe/syzkaller_logs/tree/main/230524_140757___cleanup_mnt Guest machine info: https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/machineInfo0 Reproduced code: https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/repro.c Reproduced syscall: https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/repro.prog Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/bisect_info.log Kconfig origin: https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/kconfig_origin
There was a lot of discussion yesterday about how turning the crank on syzkaller and throwing un-triaged bug reports over the wall at stressed-out xfs developers isn't particularly helpful.
There was also a very specific concern raised in that discussion:
IOWs, the bug report is deficient and not complete, and so I'm forced to spend unnecessary time trying to work out how to extract the filesystem image from a weird syzkaller report that is basically just a bunch of undocumented blobs in a github tree.
but here we are again, with another undocumented blob in a github tree, and no meaningful attempt at triage.
Syzbot at least is now providing filesystem images[1], which relieves some of the burden on the filesystem developers you're expecting to fix these bugs.
Perhaps before you send the /next/ filesystem-related syzkaller report, you can at least work out how to provide a standard filesystem image as part of the reproducer, one that can be examined with normal filesystem development and debugging tools?
[1] https://lore.kernel.org/lkml/0000000000001f239205fb969174@xxxxxxxxxx/T/
