linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: syzbot <syzbot+cbb68193bdb95af4340a@syzkaller.appspotmail.com>,
	adilger.kernel@dilger.ca, elic@nvidia.com, jasowang@redhat.com,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, parav@nvidia.com,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_setattr
Date: Sun, 14 May 2023 21:15:13 -0400	[thread overview]
Message-ID: <20230515011513.GA1905432@mit.edu> (raw)
In-Reply-To: <20230515005321.GB1903212@mit.edu>

On Sun, May 14, 2023 at 08:53:21PM -0400, Theodore Ts'o wrote:
> However, somewhere in the bisection, we start seeing this:
> 
> run #0: boot failed: WARNING in kvm_wait
   ...
> 
> 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.  :-(

Sorry, I spoke too soon.  It did get this right; it looks like it
ignores "boot failed: " messages, although it treats is as one of the
10 tries for a particular commit.

I don't see anything obviously wrong with the bisect log, although
obviously I'd want to retry some of the "All OK" results to see if
somehow things got confused.  In any case, there have been a large
number of timees where the bisection results have been less than
correct, and unfortunately, there's not much that can be done other
than just to ignore them.  It would be nice to have a human being be
able to mark the bisection as Obviously Wrong(tm), and maybe ask it do
do a slightly different bisection.

Also unfortunate is that I've had more than one case where the problem
doesn't reproduce at all using KVM, but only reproduces using #syz
test.  Which means that manual bisection may be the only way for now
to work some of these.

					- Ted

      reply	other threads:[~2023-05-15  1:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <000000000000a74de505f2349eb1@google.com>
2023-05-14 19:24 ` [syzbot] [ext4?] possible deadlock in ext4_setattr syzbot
2023-05-14 20:39   ` Michael S. Tsirkin
2023-05-15  0:53     ` Theodore Ts'o
2023-05-15  1:15       ` Theodore Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230515011513.GA1905432@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=elic@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=syzbot+cbb68193bdb95af4340a@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).