linux-kernel - Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of 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: <20171020073050.nyaqynbbkeltr7iq@gmail.com>
Date:   Fri, 20 Oct 2017 09:30:50 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Bart Van Assche <Bart.VanAssche@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "byungchul.park@....com" <byungchul.park@....com>,
        "kernel-team@....com" <kernel-team@....com>
Subject: Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of
 LOCKDEP_CROSSRELEASE

* Thomas Gleixner <tglx@...utronix.de> wrote:

> That would just make the door open for evading lockdep. This has been
> discussed when lockdep was introduced and with a lot of other 'annoying'
> debug features we've seen the same discussion happening.
> 
> When they get introduced the number of real issues and false positives is
> high, but once the dust settles it's just business as usual and the overall
> code quality improves and the number of hard to decode problems shrinks.

Yes, also note that it's typical that the proportion of false positives 
*increases* once a lock debugging feature enters a more mature period of its 
existence, because real deadlocks tend to be fixed at the development stage 
without us ever seeing them.

I.e. for every lockdep-debugged bug fixed upstream I'm pretty sure there are at 
least 10 times as many bugs that were fixed in earlier stages of development, 
without ever hitting the upstream kernel. At least that's the rough proportion
for locking bugs I introduce ;-)

So even false positives are not a problem as long as their annotation improves the 
code or documents it better.

Thanks,

	Ingo