On Thu, Nov 09, 2023 at 06:20:08PM +0100, Christian Brauner wrote: > It's a bit unfortunate that __lock_parent() locks the parent *and* may > lock the child which isn't really obvious from the name. It just becomes > clear that this is assumed by how callers release the child's lock. __lock_parent() is gone by the end of the series. > We're under rcu here. Are we sure that this can't trigger rcu timeouts > because we're spinning? Maybe there's a reason that's not an issue here. Spinning happens only if somebody is busy moving that dentry from directory to directory or back-and-forth turning it negative/positive with different inode. It's not a livelock situation - for each iteration you need a successful rename() and/or unlink()/creat() pair on the dentry in question. Coming rapidly enough to cause you spinning there... Note that lock_parent() had that loop under rcu for a long time; so did dget_parent(). I don't remember seeing rcu timeout warnings about either... > That spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED) in > __lock_parent() is there for the sake of lockdep to verify that the > parent lock is always aqcuired before the child lock? Yes.
