Re: possible circular locking dependency detected

Al Viro [off-list ref] writes:

On Fri, Sep 02, 2016 at 04:18:04PM +0100, Rainer Weikusat wrote:

quoted

As far as I can tell, this should work as I can't currently imagine
why a fs operation might end up binding a unix socket despite the
idea to make af_unix.c yet more complicated in order to work around
irregular behaviour of (as far as I can tell) a single filesystem
(for which kern_path_create doesn't really mean kern_path_create and
it has to work around that once it gets control) goes against all
instincts I have in this area. If filesystems need to do arbitrary
stuff when __sb_start_write is called for 'their' superblock, they
should be able to do so directly.

Bullshit.  kern_path_create() *does* mean the same thing in all cases.
Namely, find the parent, lock it and leave the final name component for
the create-type operation.  It sure as hell is not guaranteed to take
*all* locks that are going to be taken in process of mknod/mkdir/etc.
Never had been.

This isn't about "all locks", it's about the lock in question. No other
mknod operation (I'm aware of) calls this with another superblock than
the one already acted upon by kern_path_create. This may be wrong (if
so, feel free to correct it) but it's not "bullshit" (intentional
deception in order to sell something to someone).