Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE

[Bart Van Assche]

On Thu, 2017-10-19 at 21:12 +0200, Thomas Gleixner wrote:
> And just for the record, I wasted enough of my time already to decode 'can
> not happen' dead locks where completions or other wait primitives have been
> involved. I rather spend time annotating stuff after analyzing it proper
> than chasing happens once in a blue moon lockups which are completely
> unexplainable.
> 
> That's why lockdep exists in the first place. Ingo, Steven, myself and
> others spent an insane amount of time to fix locking bugs all over the tree
> when we started the preempt RT work. Lockdep was a rescue because it forced
> people to look at their own crap and if it was 100% clear that lockdep
> tripped a false positive either lockdep was fixed or the code in question
> annotated, which is a good thing because that's documentation at the same
> time.

Hello Thomas,

In case it wouldn't be clear, your work and the work of others on lockdep
and preempt-rt is highly appreciated. Sorry that I missed the discussion
about the cross-release functionality when it went upstream. I have several
questions about that functionality:
* 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?
* 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?
* 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.

Thanks,

Bart.