Message-ID: <20190710161331.GA801@sol.localdomain>
Date:   Wed, 10 Jul 2019 09:13:31 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Bart Van Assche <bvanassche@....org>
Cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        syzkaller-bugs@...glegroups.com, jeffv@...gle.com
Subject: Re: Reminder: 5 open syzbot bugs in lockdep subsystem

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

Powered by blists - more mailing lists