linux-kernel - Re: [RFC] Are you good with Lockdep?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201112085114.GC14554@X58A-UD3R>
Date:   Thu, 12 Nov 2020 17:51:14 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     torvalds@...ux-foundation.org, peterz@...radead.org,
        mingo@...hat.com, will@...nel.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, rostedt@...dmis.org, joel@...lfernandes.org,
        alexander.levin@...rosoft.com, daniel.vetter@...ll.ch,
        chris@...is-wilson.co.uk, duyuyang@...il.com,
        johannes.berg@...el.com, tj@...nel.org, tytso@....edu,
        willy@...radead.org, david@...morbit.com, amir73il@...il.com,
        bfields@...ldses.org, gregkh@...uxfoundation.org,
        kernel-team@....com
Subject: Re: [RFC] Are you good with Lockdep?

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.

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