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]

Date:   Thu, 19 Oct 2017 22:49:27 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Bart Van Assche <Bart.VanAssche@....com>
cc:     "mingo@...nel.org" <mingo@...nel.org>,
        "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

On Thu, 19 Oct 2017, Bart Van Assche wrote:
> * How many lock inversion problems have been found so far thanks to the
>   cross-release checking? How many false positives have the cross-release
>   checks triggered so far? Does the number of real issues that has been
>   found outweigh the effort spent on suppressing false positives?

That's bean counting which is completely irrelevant. Real issues and false
positives are both problems which need to be looked at carefully.

- The deadlock needs to be fixed, which is obvious.

- The false positive needs to be annotated, which is a good thing in
  several aspects:

  It proofs that this was done intentional and is correct and the
  annotation documents it at the same time in the code.

  I'm pretty sure that except for a few obvious ones the effort to prove
  that a false positive is a false positive is substantial, but not proving
  it would either be arrogant or outright stupid.

So it's not a N > M question. Even if the number of false positives is
higher than the number of real deadlocks, then everyone out in the field
who had to stare at his server once a year not making progress and not
telling why will appreciate that these obscure issues are gone.

> * What alternatives have been considered other than enabling cross-release
>   checking for all locking objects that support releasing from the context
>   of another task than the context from which the lock was obtained? Has it
>   e.g. been considered to introduce two versions of the lock objects that
>   support cross-releases - one version for which lock inversion checking is
>   always enabled and another version for which lock inversion checking is
>   always disabled?

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.

> * How much review has the Documentation/locking/crossrelease.txt received
>   before it went upstream? At least to me that document seems much harder
>   to read than other kernel documentation due to weird use of the English
>   grammar.

It was reviewed, and yes it could do with some polishing, but it's a good
start.

Thanks,

	tglx