Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755076AbdLOHiz (ORCPT ); Fri, 15 Dec 2017 02:38:55 -0500 Received: from mail-lf0-f65.google.com ([209.85.215.65]:42533 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755055AbdLOHiv (ORCPT ); Fri, 15 Dec 2017 02:38:51 -0500 X-Google-Smtp-Source: ACJfBovtPGtFVMf4J6Tfz6CjSZjVb8L9PMgPIxqo4EXus6tkTECSImJZ3nmvoVAGTFcSUQ29vTGivyHCV9Xy3itbX8Y= MIME-Version: 1.0 In-Reply-To: <20171215062428.5dyv7wjbzn2ggxvz@thunk.org> References: <20171213104617.7lffucjhaa6xb7lp@gmail.com> <20171215062428.5dyv7wjbzn2ggxvz@thunk.org> From: Byungchul Park Date: Fri, 15 Dec 2017 16:38:47 +0900 Message-ID: Subject: Re: [PATCH] locking/lockdep: Remove the cross-release locking checks To: "Theodore Ts'o" , Byungchul Park , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , david@fromorbit.com, 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: 2109 Lines: 54 On Fri, Dec 15, 2017 at 3:24 PM, Theodore Ts'o wrote: > On Fri, Dec 15, 2017 at 01:05:43PM +0900, Byungchul Park wrote: >> For example, in the case of fs issues, for now we can >> invalidate wait_for_completion() in submit_bio_wait().... > > And this will spawn a checkpatch.pl ERROR: > > ERROR("LOCKDEP", > "lockdep_no_validate class is reserved for device->mutex.\n" . $herecurr); > > This mention in checkpatch.pl is the only documentation I've been able > to find about lockdep_set_novalidate_class(), by the way. > >> ... and re-validate it later, of course, I really want to find more >> fundamental solution though. > > Oh, and I was finally able to find the quote that the *only* people > who are likely to be able to deal with lock annotations are the Right. Using the word, "only", is one that I should not have done and I apologize for. They are just "only" people who solve and classify locks quickly, assuming all of kernel guys are familiar with lockdep annotations. Thus, even this statement is bad as well, since no good document for that exists, as you pointed out. I agree. > subsystem maintainers. But if the ways of dealing with lock > annotations are not documented, such that subsystem maintainers are > going to have a very hard time figuring out *how* to deal with it, it Right. I've agreed with this, since you pointed out it's problem not to be documented well. > seems that lock classification as a solution to cross-release false > positives seems.... unlikely: > > From: Byungchul Park > Date: Fri, 8 Dec 2017 18:27:45 +0900 > Subject: Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray > > 1) Firstly, it's hard to assign lock classes *properly*. By > default, it relies on the caller site of lockdep_init_map(), > but we need to assign another class manually, where ordering > rules are complicated so cannot rely on the caller site. That > *only* can be done by experts of the subsystem. > > - Ted -- Thanks, Byungchul