Hi Dave, On 2023-05-25 at 16:15:01 +1000, Dave Chinner wrote: > 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. > Thanks Dave Chinner's patient suggestion! Thanks syzkaller maintainer Aleksandr Nogikh's guidance! I put the generated filesystem image file0.gz for mounting in link: https://github.com/xupengfe/syzkaller_logs/raw/main/230524_140757___cleanup_mnt/file0.gz And could "gunzip file0.gz" to get file0. Thanks! BR. > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
