| Message ID | 20231101062104.2104951-6-viro@zeniv.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/15] fast_dput(): having ->d_delete() is not reason to delay refcount decrement | expand |
diff --git a/fs/dcache.c b/fs/dcache.c index 0114b5195535..c89337ae30ce 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -729,6 +729,7 @@ static struct dentry *dentry_kill(struct dentry *dentry) goto slow_positive; } } + dentry->d_lockref.count--; __dentry_kill(dentry); return parent; @@ -741,6 +742,7 @@ static struct dentry *dentry_kill(struct dentry *dentry) if (unlikely(dentry->d_lockref.count != 1)) { dentry->d_lockref.count--; } else if (likely(!retain_dentry(dentry))) { + dentry->d_lockref.count--; __dentry_kill(dentry); return parent; } else {
Currently we call it with ->d_count equal to 1 when called from dentry_kill(); all other callers have ->d_count equal to 0. Make it always be called with zero ->d_count; on this step we just decrement it before the calls in dentry_kill(). That is safe, since all places that care about the value of ->d_count either do that under ->d_lock or hold a reference to dentry in question. Either is sufficient to prevent observing a dentry immediately prior to __dentry_kill() call from dentry_kill(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- fs/dcache.c | 2 ++ 1 file changed, 2 insertions(+)