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. There is bzImage v6.4-rc3 in link: https://github.com/xupengfe/syzkaller_logs/blob/main/230524_140757___cleanup_mnt/bzImage_v64rc3 You could use it to boot v6.4-rc3 kernel. ./start3.sh // it needs qemu-system-x86_64 and I used v7.1.0 // start3.sh will load bzImage_2241ab53cbb5cdb08a6b2d4688feb13971058f65 v6.2-rc5 kernel // You could change the bzImage_xxx as you want You could use below command to log in, there is no password for root. ssh -p 10023 root@localhost After login vm(virtual machine) successfully, you could transfer reproduced binary to the vm by below way, and reproduce the problem in vm: gcc -pthread -o repro repro.c scp -P 10023 repro root@localhost:/root/ Then you could reproduce this issue easily in above environment. Thanks! BR. > [1] > https://lore.kernel.org/lkml/0000000000001f239205fb969174@xxxxxxxxxx/T/ > >
