[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180103070556.GA22583@thunk.org>
Date: Wed, 3 Jan 2018 02:05:56 -0500
From: Theodore Ts'o <tytso@....edu>
To: Byungchul Park <byungchul.park@....com>
Cc: Matthew Wilcox <willy@...radead.org>,
Byungchul Park <max.byungchul.park@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>, david@...morbit.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
Amir Goldstein <amir73il@...il.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
oleg@...hat.com, kernel-team@....com, daniel@...ll.ch
Subject: Re: About the try to remove cross-release feature entirely by Ingo
On Wed, Jan 03, 2018 at 11:10:37AM +0900, Byungchul Park wrote:
> > The point I was trying to drive home is that "all we have to do is
> > just classify everything well or just invalidate the right lock
>
> Just to be sure, we don't have to invalidate lock objects at all but
> a problematic waiter only.
So essentially you are proposing that we have to play "whack-a-mole"
as we find false positives, and where we may have to put in ad-hoc
plumbing to only invalidate "a problematic waiter" when it's
problematic --- or to entirely suppress the problematic waiter
altogether. And in that case, a file system developer might be forced
to invalidate a lock/"waiter"/"completion" in another subsystem.
I will also remind you that doing this will trigger a checkpatch.pl
*error*:
ERROR("LOCKDEP", "lockdep_no_validate class is reserved for device->mutex.\n" . $herecurr);
- Ted
Powered by blists - more mailing lists