diff options
author | Ingo Molnar <mingo@kernel.org> | 2017-12-12 12:31:16 +0100 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2017-12-12 12:38:51 +0100 |
commit | e966eaeeb623f09975ef362c2866fae6f86844f9 (patch) | |
tree | 8dfcb814c86d24c32ae3338d4dc1dc3aa1017764 /net | |
parent | d89c70356acf11b7cf47ca5cfcafae5062a85451 (diff) | |
download | linux-e966eaeeb623f09975ef362c2866fae6f86844f9.tar.bz2 |
locking/lockdep: Remove the cross-release locking checks
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and CONFIG_LOCKDEP_COMPLETIONS=y),
while it found a number of old bugs initially, was also causing too many
false positives that caused people to disable lockdep - which is arguably
a worse overall outcome.
If we disable cross-release by default but keep the code upstream then
in practice the most likely outcome is that we'll allow the situation
to degrade gradually, by allowing entropy to introduce more and more
false positives, until it overwhelms maintenance capacity.
Another bad side effect was that people were trying to work around
the false positives by uglifying/complicating unrelated code. There's
a marked difference between annotating locking operations and
uglifying good code just due to bad lock debugging code ...
This gradual decrease in quality happened to a number of debugging
facilities in the kernel, and lockdep is pretty complex already,
so we cannot risk this outcome.
Either cross-release checking can be done right with no false positives,
or it should not be included in the upstream kernel.
( Note that it might make sense to maintain it out of tree and go through
the false positives every now and then and see whether new bugs were
introduced. )
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions