Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751517AbdLMHNP (ORCPT ); Wed, 13 Dec 2017 02:13:15 -0500 Received: from mail-lf0-f51.google.com ([209.85.215.51]:40558 "EHLO mail-lf0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750749AbdLMHNK (ORCPT ); Wed, 13 Dec 2017 02:13:10 -0500 X-Google-Smtp-Source: ACJfBotQX8NyNaVUwkueOhyoUceqnibRXiyTurlglha4Sh1NTelMrlerQFcgNN+QZrMpR9MegzQsVhBbYwKmEBCXdXU= MIME-Version: 1.0 In-Reply-To: References: From: Byungchul Park Date: Wed, 13 Dec 2017 16:13:07 +0900 Message-ID: Subject: Re: About the try to remove cross-release feature entirely by Ingo To: Thomas Gleixner , Peter Zijlstra , Ingo Molnar , david@fromorbit.com, tytso@mit.edu, willy@infradead.org, Linus Torvalds , Amir Goldstein , byungchul.park@lge.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, oleg@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2011 Lines: 61 On Wed, Dec 13, 2017 at 3:24 PM, Byungchul Park 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