diff options
author | Nick Piggin <npiggin@kernel.dk> | 2011-01-14 02:36:19 +0000 |
---|---|---|
committer | Nick Piggin <npiggin@hera.kernel.org> | 2011-01-14 02:36:19 +0000 |
commit | 90dbb77ba48dddb87445d238e84cd137cf97dd98 (patch) | |
tree | 446772602e5944075a6c614db05dd06681f3f3d8 | |
parent | bb20c18db6fbb5e6ba499c76473a487d35073467 (diff) | |
download | op-kernel-dev-90dbb77ba48dddb87445d238e84cd137cf97dd98.zip op-kernel-dev-90dbb77ba48dddb87445d238e84cd137cf97dd98.tar.gz |
fs: fix dropping of rcu-walk from force_reval_path
As J. R. Okajima noted, force_reval_path passes in the same dentry to
d_revalidate as the one in the nameidata structure (other callers pass in a
child), so the locking breaks. This can oops with a chrooted nfs mount, for
example. Similarly there can be other problems with revalidating a dentry
which is already in nameidata of the path walk.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
-rw-r--r-- | fs/namei.c | 8 |
1 files changed, 8 insertions, 0 deletions
@@ -479,6 +479,14 @@ static int nameidata_dentry_drop_rcu(struct nameidata *nd, struct dentry *dentry struct fs_struct *fs = current->fs; struct dentry *parent = nd->path.dentry; + /* + * It can be possible to revalidate the dentry that we started + * the path walk with. force_reval_path may also revalidate the + * dentry already committed to the nameidata. + */ + if (unlikely(parent == dentry)) + return nameidata_drop_rcu(nd); + BUG_ON(!(nd->flags & LOOKUP_RCU)); if (nd->root.mnt) { spin_lock(&fs->lock); |