Re: About the try to remove cross-release feature entirely by Ingo

[Byungchul Park <byungchul.park@lge.com>]

On 1/2/2018 1:00 AM, Theodore Ts'o wrote:
> On Mon, Jan 01, 2018 at 02:18:55AM -0800, Matthew Wilcox wrote:
>>> Clarification: all TCP connections that are used by kernel code would
>>> need to be in their own separate lock class.  All TCP connections used
>>> only by userspace could be in their own shared lock class.  You can't
>>> use a one lock class for all kernel-used TCP connections, because of
>>> the Network Block Device mounted on a local file system which is then
>>> exported via NFS and squirted out yet another TCP connection problem.
>>
>> So the false positive you're concerned about is write-comes-in-over-NFS
>> (with socket lock held), NFS sends a write request to local filesystem,
>> local filesystem sends write to block device, block device sends a
>> packet to a socket which takes that socket lock.
> 
> It's not just the socket lock, but any of the locks/mutexes/"waiters"
> that might be taken in the TCP code path and below, including in the
> NIC driver.
> 
>> I don't think we need to be as drastic as giving each socket its own lock
>> class to solve this.  All NFS sockets can be in lock class A; all NBD
>> sockets can be in lock class B; all user sockets can be in lock class
>> C; etc.
> 
> But how do you know which of the locks taken in the networking stack
> are for the NBD versus the NFS sockets?  What manner of horrific
> abstraction violation is going to pass that information all the way
> down to all of the locks that might be taken at the socket layer and
> below?
> 
> How is this "proper clasification" supposed to happen?  It's the
> repeated handwaving which claims this is easy which is rather
> frustrating.  The simple thing is to use a unique ID which is bumped
> for each struct sock, each struct super, struct block_device, struct
> request_queue, struct bdi, etc, but that runs into lockdep scalability
> issues.

This is what I mentioned with group ID in an example for you before.
To do that, the most important thing is to prevent running into
lockdep scalability.

-- 
Thanks,
Byungchul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>