Instead of bumping it from 0 to 1, calling retain_dentry(), then
decrementing it back to 0 (with ->d_lock held all the way through),
just leave refcount at 0 through all of that.
It will have a visible effect for ->d_delete() - now it can be
called with refcount 0 instead of 1 and it can no longer play
silly buggers with dropping/regaining ->d_lock. Not that any
in-tree instances tried to (it's pretty hard to get right).
Any out-of-tree ones will have to adjust (assuming they need any
changes).
Note that we do not need to extend rcu-critical area here - we have
verified that refcount is non-negative after having grabbed ->d_lock,
so nobody will be able to free dentry until they get into __dentry_kill(),
which won't happen until they manage to grab ->d_lock.
Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
---
fs/dcache.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 7931f5108581..30bebec591db 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -888,15 +888,14 @@ void dput(struct dentry *dentry)
}
/* Slow case: now with the dentry lock held */
- dentry->d_lockref.count = 1;
rcu_read_unlock();
if (likely(retain_dentry(dentry))) {
- dentry->d_lockref.count--;
spin_unlock(&dentry->d_lock);
return;
}
+ dentry->d_lockref.count = 1;
dentry = dentry_kill(dentry);
}
}
@@ -921,13 +920,8 @@ void dput_to_list(struct dentry *dentry, struct list_head *list)
return;
}
rcu_read_unlock();
- dentry->d_lockref.count = 1;
- if (!retain_dentry(dentry)) {
- --dentry->d_lockref.count;
+ if (!retain_dentry(dentry))
to_shrink_list(dentry, list);
- } else {
- --dentry->d_lockref.count;
- }
spin_unlock(&dentry->d_lock);
}
--
2.39.2
