linux-kernel - Re: Linux 3.15 .. and continuation of merge window

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140611123022.GW18016@ZenIV.linux.org.uk>
Date:	Wed, 11 Jun 2014 13:30:22 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"J. R. Okajima" <hooanon05g@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.15 .. and continuation of merge window

On Wed, Jun 11, 2014 at 06:32:58PM +0900, J. R. Okajima wrote:
> 
> Al Viro:
> > So I suspect that the right fix is a bit trickier - in addition to check
> > on the fast path (i.e. when trylock gets us the lock on parent), we need
> > to
> > 	* get rcu_read_lock() before dropping ->d_lock.
> > 	* check if dentry is already doomed right after taking rcu_read_lock();
> > if not, any value we might see in ->d_parent afterwards will point to object
> > not freed until we drop rcu_read_lock.
> >
> > IOW, something like the delta below.  Comments?
> 
> I will try testing later.
> For now, as a comment before testing, the patch looks weird for me. It
> checks d_lockref.count twice during d_lockref.lock held. It must be the
> same result, isn't it?

Right you are.  So what we need is
	* check that thing once, as in your variant (I'd still prefer to
check ->d_lockref.count instead of ->d_flags, but it's the same thing being
tested)
	* ... and get rcu_read_lock() *before* dropping ->d_lock.

The former guarantees that the address we are doing trylock on would be that
of a live dentry.  The latter makes sure that anything assigned to 
dentry->d_parent after we drop ->d_lock will not be freed until we drop
rcu_read_lock.

Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
---
diff --git a/fs/dcache.c b/fs/dcache.c
index be2bea8..e99c6f5 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -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);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/