* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > 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. Yes, also note that it's typical that the proportion of false positives *increases* once a lock debugging feature enters a more mature period of its existence, because real deadlocks tend to be fixed at the development stage without us ever seeing them. I.e. for every lockdep-debugged bug fixed upstream I'm pretty sure there are at least 10 times as many bugs that were fixed in earlier stages of development, without ever hitting the upstream kernel. At least that's the rough proportion for locking bugs I introduce ;-) So even false positives are not a problem as long as their annotation improves the code or documents it better. Thanks, Ingo -- 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>
