Re: [Syzkaller & bisect] There is "soft lockup in __cleanup_mnt" in v6.4-rc3 kernel

[Pengfei Xu <pengfei.xu@intel.com>]

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@fromorbit.com