On Wed, Dec 13, 2017 at 3:24 PM, Byungchul Park <max.byungchul.park@xxxxxxxxx> wrote: > Lockdep works, based on the following: > > (1) Classifying locks properly > (2) Checking relationship between the classes > > If (1) is not good or (2) is not good, then we > might get false positives. > > For (1), we don't have to classify locks 100% > properly but need as enough as lockdep works. > > For (2), we should have a mechanism w/o > logical defects. > > Cross-release added an additional capacity to > (2) and requires (1) to get more precisely classified. > > Since the current classification level is too low for > cross-release to work, false positives are being > reported frequently with enabling cross-release. > Yes. It's a obvious problem. It needs to be off by > default until the classification is done by the level > that cross-release requires. > > But, the logic (2) is valid and logically true. Please > keep the code, mechanism, and logic. In addition, I want to say that the current level of classification is much less than 100% but, since we have annotated well to suppress wrong reports by rough classifications, finally it does not come into view by original lockdep for now. But since cross-release makes the dependency graph more fine-grained, it easily comes into view. Even w/o cross-release, it can happen by adding additional dependencies connecting two roughly classified lock classes in the future. Furthermore, I can see many places in kernel to consider wait_for_completion() using manual lock_acquire()/lock_release() and the rate using it raises. In other words, even without cross-release, the more we add manual annotations for wait_for_completion() the more we definitely suffer same problems someday, we are facing now through cross-release. Therefore, I want to say the fundamental problem comes from classification, not cross-release specific. Of course, since cross-release accelerates the condition, I agree with it to be off for now. -- Thanks, Byungchul
