| Message ID | 20180222235025.28662-6-john.ogness@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Feb 23, 2018 at 12:50:24AM +0100, John Ogness wrote: > - while (dentry && !lockref_put_or_lock(&dentry->d_lockref)) { > - parent = lock_parent(dentry); > - if (dentry->d_lockref.count != 1) { > - dentry->d_lockref.count--; > - spin_unlock(&dentry->d_lock); > - if (parent) > - spin_unlock(&parent->d_lock); > - break; > - } > - inode = dentry->d_inode; /* can't be NULL */ > - if (unlikely(!spin_trylock(&inode->i_lock))) { > - spin_unlock(&dentry->d_lock); > - if (parent) > - spin_unlock(&parent->d_lock); > - cpu_relax(); > - continue; > - } > - __dentry_kill(dentry); > - dentry = parent; > - } > + while (dentry && !lockref_put_or_lock(&dentry->d_lockref)) > + dentry = dentry_kill(dentry); Hmm... OK, that's interesting. I agree that it looks similar to dentry_kill() loop, with one exception - here we are aggressively pruning the branch. None of the "do we want to retain that sucker" stuff here. It doesn't matter for most of the callers, with one exception: prune_dcache_sb(). OTOH, there it just might be the right thing to do anyway - after all, it matters only if somebody has grabbed and dropped the sucker while we'd been trying to do lock_parent(). Had we lost the race with their dput(), we would've left the damn thing alone, and we are called from a memory shrinker, so we'll get called again if needed.
diff --git a/fs/dcache.c b/fs/dcache.c index 082361939b84..e470d49daa54 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1130,26 +1130,8 @@ static void shrink_dentry_list(struct list_head *list) * fragmentation. */ dentry = parent; - while (dentry && !lockref_put_or_lock(&dentry->d_lockref)) { - parent = lock_parent(dentry); - if (dentry->d_lockref.count != 1) { - dentry->d_lockref.count--; - spin_unlock(&dentry->d_lock); - if (parent) - spin_unlock(&parent->d_lock); - break; - } - inode = dentry->d_inode; /* can't be NULL */ - if (unlikely(!spin_trylock(&inode->i_lock))) { - spin_unlock(&dentry->d_lock); - if (parent) - spin_unlock(&parent->d_lock); - cpu_relax(); - continue; - } - __dentry_kill(dentry); - dentry = parent; - } + while (dentry && !lockref_put_or_lock(&dentry->d_lockref)) + dentry = dentry_kill(dentry); } }
shrink_dentry_list() holds dentry->d_lock and needs to acquire dentry->d_inode->i_lock. This cannot be done with a spin_lock() operation because it's the reverse of the regular lock order. To avoid ABBA deadlocks it is done with a trylock loop. Trylock loops are problematic in two scenarios: 1) PREEMPT_RT converts spinlocks to 'sleeping' spinlocks, which are preemptible. As a consequence the i_lock holder can be preempted by a higher priority task. If that task executes the trylock loop it will do so forever and live lock. 2) In virtual machines trylock loops are problematic as well. The VCPU on which the i_lock holder runs can be scheduled out and a task on a different VCPU can loop for a whole time slice. In the worst case this can lead to starvation. Commits 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") and 046b961b45f9 ("shrink_dentry_list(): take parent's d_lock earlier") are addressing exactly those symptoms. Avoid the trylock loop by using dentry_kill(). When pruning ancestors, the same code applies that is used to kill a dentry in dput(). This also has the benefit that the locking order is now the same. First the inode is locked, then the parent. Signed-off-by: John Ogness <john.ogness@linutronix.de> --- fs/dcache.c | 22 ++-------------------- 1 file changed, 2 insertions(+), 20 deletions(-)