lkml.org 
[lkml]   [2020]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Are you good with Lockdep?
On Thu, Nov 12, 2020 at 05:51:14PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote:
> > > If on the other hand there's some bug in lockdep itself that causes
> > > excessive false positives, it's better to limit the number of reports
> > > to one per bootup, so that it's not seen as a nuisance debugging
> > > facility.
> > >
> > > Or if lockdep gets extended that causes multiple previously unreported
> > > (but very much real) bugs to be reported, it's *still* better to
> > > handle them one by one: because lockdep doesn't know whether it's real
> >
> > Why do you think we cannot handle them one by one with multi-reporting?
> > We can handle them with the first one as we do with single-reporting.
> > And also that's how we work, for example, when building the kernel or
> > somethinig.
>
> Let me add a little bit more. I just said the fact that we are able to
> handle the bugs one by one as if we do with single-reporting.
>
> But the thing is multi-reporting could be more useful in some cases.
> More precisely speaking, bugs not caused by IRQ state will be reported
> without annoying nuisance. I bet you have experienced a ton of nuisances
> when multi-reporting Lockdep detected a deadlock by IRQ state.

Last, we should never use multi-reporting Lockdep if Lockdep works like
the current code because redundant warnings caused by IRQ state would be
reported almost infinite times. I'm afraid you were talking about it.

Thanks,
Byungchul

> For some cases, multi-reporting is as useful as single-reporting, while
> for the other cases, multi-reporting is more useful. Then I think we
> have to go with mutil-reporting if there's no technical issue.
>
> Thanks,
> Byungchul

\
 
 \ /
  Last update: 2020-11-12 10:48    [W:0.181 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site