On Fri, Mar 15, 2019 at 09:56:32AM +1100, Tobin C. Harding wrote: > Could someone please explain to me how the locking order commented at > the top of the file is not violated in the following: > > >From top of fs/dcache.c > > * If there is an ancestor relationship: > * dentry->d_parent->...->d_parent->d_lock > * ... > * dentry->d_parent->d_lock > * dentry->d_lock > > > dentry_kill() appears to require caller to hold the dentry->d_lock yet > it locks the parent with spin_trylock(&parent->d_lock), if this > fails it calls __lock_parent() which releases the dentry->d_lock before > locking the parent and re-acquiring [1] the dentry->d_lock . Is this not > locking in two different orders? What you're describing here is how we work around having to lock in the wrong order. There are "a few" places in the kernel where we do this. Calling spin_trylock() won't deadlock -- it'll just return failure. At that point, we drop the child, spin waiting for the parent, then lock the child. > [1] I do not fully understand the spin_lock_nested() macro. It describes to lockdep that, while it looks like we're acquiring a lock that we already own, there's actually a hierarchy of locks that are in the same lock class; we're attempting to acquire a lock in "subclass N". N is allowed to be between 0-7, inclusive.
