[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171230224028.GC3366@thunk.org>
Date: Sat, 30 Dec 2017 17:40:28 -0500
From: Theodore Ts'o <tytso@....edu>
To: Matthew Wilcox <willy@...radead.org>
Cc: Byungchul Park <byungchul.park@....com>,
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 Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote:
>
> I'm not sure I agree with this part. What if we add a new TCP lock class
> for connections which are used for filesystems/network block devices/...?
> Yes, it'll be up to each user to set the lockdep classification correctly,
> but that's a relatively small number of places to add annotations,
> and I don't see why it wouldn't work.
I was exagerrating a bit for effect, I admit. (but only a bit).
It can probably be for all TCP connections that are used by kernel
code (as opposed to userspace-only TCP connections). But it would
probably have to be each and every device-mapper instance, each and
every block device, each and every mounted file system, each and every
bdi object, etc.
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
objects" is a massive understatement of the complexity level of what
would be required, or the number of locks/completion handlers that
would have to be blacklisted.
- Ted
Powered by blists - more mailing lists