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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>