On Thu, Mar 14, 2019 at 04:09:05PM -0700, Matthew Wilcox wrote: > 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. ok, cool. Thanks for taking the time to explain this. Tobin
