Re: [syzbot] [ext4?] possible deadlock in ext4_setattr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 14, 2023 at 04:39:36PM -0400, Michael S. Tsirkin wrote:
> On Sun, May 14, 2023 at 12:24:32PM -0700, syzbot wrote:
> > syzbot has bisected this issue to:
> > 
> > commit a3c06ae158dd6fa8336157c31d9234689d068d02
> > Author: Parav Pandit <parav@xxxxxxxxxx>
> > Date:   Tue Jan 5 10:32:03 2021 +0000
> > 
> >     vdpa_sim_net: Add support for user supported devices
> > 
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> I don't see how this can be related, I don't think the test setup uses
> vdpa sim at all.

Yeah, it's totally bogus.  You can see it by looking at the bisection
log[1].

[1] https://syzkaller.appspot.com/text?tag=Log&x=16e372c6280000

The initial bisection logs make it clear that it is *trivially* easy
to reproduce, and that the failure signature is:

crashed: possible deadlock in {ext4_xattr_set_handle,ext4_setattr,ext4_xattr_set_handle}

However, somewhere in the bisection, we start seeing this:

run #0: boot failed: WARNING in kvm_wait
run #1: boot failed: WARNING in kvm_wait
run #2: OK
run #3: OK
run #4: OK
run #5: OK
run #6: OK
run #7: OK
run #8: OK
run #9: OK

This is a completely different failure signature, and the "WARNING in
kvm_wait" should be ignored, and this should be considered a "git
bisect good".  However, the syzkaller bisection doesn't understand
this, and so it gets sent down the primrose path.  :-(

Unfortunately, there isn't a good way to tell the syzkaller bisection,
"go home, your drunk", and to tell it to try again, perhaps with a
human-supplied discriminator of what should be considered a valid
failure signature.

In the ideal world, a human should be able to give it a setup set of
bisection "good" and "bad" commits, along with a regexp for what a
failure should look like, and perhaps with a hint of how many tries it
should use before assuming that a bisection result is "good", and to
teach it to assume that the bisection has "bad" after seeing a single
failure signature.

If the above is too much to ask, in the slightly-less-ideal world,
there would be a way to give "#syz test" a count argument, so we could
have syzkaller try N times, for when we need to do a manual bisection
using "#syz test"....

						- Ted



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux