On Thu, May 25, 2023 at 01:44:31PM +0800, Pengfei Xu wrote: > On 2023-05-24 at 22:51:27 -0500, Eric Sandeen wrote: > > 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? > > > There is a standard filesystem image after > > git clone https://gitlab.com/xupengfe/repro_vm_env.git > cd repro_vm_env > tar -xvf repro_vm_env.tar.gz > image is named as centos8_3.img, and will boot by start3.sh. No. That is not the filesystem image that is being asked for. The syzkaller reproducer (i.e. what you call repro.c) contructs a filesystem image in it's own memory which it then mounts and runs the test operations on. That's the filesystem image that we need extracted into a separate image file because that's the one that is corrupted and we need to look at when triaging these issues. Google's syzbot does this now, so your syzkaller bot should also be able to do it. Please go and talk to the syzkaller authors to find out how they extract filesystem images from the reproducer, and any other information they've also been asked to provide for triage purposes. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
