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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
