Skip to content

Commit

Permalink
lock_parent: don't step on stale ->d_parent of all-but-freed one
Browse files Browse the repository at this point in the history
Dentry that had been through (or into) __dentry_kill() might be seen
by shrink_dentry_list(); that's normal, it'll be taken off the shrink
list and freed if __dentry_kill() has already finished.  The problem
is, its ->d_parent might be pointing to already freed dentry, so
lock_parent() needs to be careful.

We need to check that dentry hasn't already gone into __dentry_kill()
*and* grab rcu_read_lock() before dropping ->d_lock - the latter makes
sure that whatever we see in ->d_parent after dropping ->d_lock it
won't be freed until we drop rcu_read_lock().

Signed-off-by: Al Viro <[email protected]>
  • Loading branch information
Al Viro committed Jun 12, 2014
1 parent 9c1d528 commit c2338f2
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion fs/dcache.c
Original file line number Diff line number Diff line change
Expand Up @@ -532,10 +532,12 @@ static inline struct dentry *lock_parent(struct dentry *dentry)
struct dentry *parent = dentry->d_parent;
if (IS_ROOT(dentry))
return NULL;
if (unlikely((int)dentry->d_lockref.count < 0))
return NULL;
if (likely(spin_trylock(&parent->d_lock)))
return parent;
spin_unlock(&dentry->d_lock);
rcu_read_lock();
spin_unlock(&dentry->d_lock);
again:
parent = ACCESS_ONCE(dentry->d_parent);
spin_lock(&parent->d_lock);
Expand Down

0 comments on commit c2338f2

Please sign in to comment.