[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANrsvRMAci5Vxj0kKsgW4-cgK4X4BAvq9jOwkAx0TWHqBjogVw@mail.gmail.com>
Date: Wed, 13 Dec 2017 16:13:07 +0900
From: Byungchul Park <max.byungchul.park@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>, david@...morbit.com,
tytso@....edu, willy@...radead.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Amir Goldstein <amir73il@...il.com>, byungchul.park@....com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
oleg@...hat.com
Subject: Re: About the try to remove cross-release feature entirely by Ingo
On Wed, Dec 13, 2017 at 3:24 PM, Byungchul Park
<max.byungchul.park@...il.com> 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
Powered by blists - more mailing lists