[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230515005321.GB1903212@mit.edu>
Date: Sun, 14 May 2023 20:53:21 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: syzbot <syzbot+cbb68193bdb95af4340a@...kaller.appspotmail.com>,
adilger.kernel@...ger.ca, elic@...dia.com, jasowang@...hat.com,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, parav@...dia.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_setattr
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@...dia.com>
> > 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
Powered by blists - more mailing lists