All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	syzkaller-bugs@googlegroups.com, jeffv@google.com
Subject: Re: Reminder: 5 open syzbot bugs in lockdep subsystem
Date: Wed, 10 Jul 2019 09:13:31 -0700	[thread overview]
Message-ID: <20190710161331.GA801@sol.localdomain> (raw)
In-Reply-To: <f614ac47-34c3-fac4-c096-fd835ce6d35a@acm.org>

Hi Bart,

On Wed, Jul 10, 2019 at 07:14:10AM -0700, Bart Van Assche wrote:
> On 7/9/19 10:58 PM, Eric Biggers wrote:
> > [This email was generated by a script.  Let me know if you have any suggestions
> > to make it better, or if you want it re-generated with the latest status.]
> > 
> > Of the currently open syzbot reports against the upstream kernel, I've manually
> > marked 5 of them as possibly being bugs in the lockdep subsystem.  I've listed
> > these reports below, sorted by an algorithm that tries to list first the reports
> > most likely to be still valid, important, and actionable.
> > 
> > Of these 5 bugs, 3 were seen in mainline in the last week.
> > 
> > Of these 5 bugs, 1 was bisected to a commit from the following person:
> > 
> > 	Bart Van Assche <bvanassche@acm.org>
> 
> (+jeffv)
> 
> Hi Eric,
> 
> Several days ago I had already explained to you that the bisection result
> that led to one of my commits did not make any sense to me. So I do not
> appreciate this kind of fingerpointing. Please stop doing this.
> 
> Bart.
> 

To be clear, the email you sent saying the bisection was messed up was 3 months
ago (not "several days ago") , and was on the list, not to me personally:
https://lore.kernel.org/lkml/f71aaffa-ecf4-1def-fe50-91f37c677537@acm.org/
And at the time you didn't give any reason why your commit can't be responsible.

I then responded yesterday and explained why another crash showed up at the end
of the bisection log, and why I think the bisection result is actually correct
(https://lore.kernel.org/lkml/20190710053030.GB2152@sol.localdomain/).  BTW, I
even took the time to manually verify that the issue is not present in the
commit immediately before your commit, and that it appears when just
"kernel/workqueue: Use dynamic lockdep keys for workqueues" and
"locking/lockdep: Shrink struct lock_class_key" are applied (the latter is
needed to fix a WARNING the reproducer also causes).

I then sent out this reminder to group together the syzbot reports where the
lockdep limits are reached, in the hope that they would be related, and helpful
to you and the lockdep maintainers.  Since one bug had a bisection result that I
had manually reviewed and believed to be accurate, my reminder mentions that
result for that bug, just like I've been doing when I've been sending out syzbot
reminders for other subsystems.

I disagree that I should stop including bisection results (namely, the ones that
I've manually reviewed and believed to be accurate; the raw results reported by
syzbot are not too accurate, so I haven't been including them without review) in
reminders because it's "finger pointing".  They can be very helpful for fixing
bugs and getting the right people to work on them.  In fact, people often refuse
to fix syzbot bugs that do not have bisection results, because they expect a
bisection result before they bother to take a look at it.

Anyway, this bug is still there in mainline Linux, regardless of whose fault it
is.  None of this changes the fact that someone needs to fix it.  I'll look into
it more if I have time, though this very much seems to be in lockdep territory,
and there are 500 other syzbot bugs that need to be worked on too.

- Eric

      reply	other threads:[~2019-07-10 16:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  5:58 Reminder: 5 open syzbot bugs in lockdep subsystem Eric Biggers
2019-07-10 14:14 ` Bart Van Assche
2019-07-10 16:13   ` Eric Biggers [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=20190710161331.GA801@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=jeffv@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.