From: Paul E. McKenney on
On Thu, Jun 24, 2010 at 01:02:36PM +1000, npiggin(a)suse.de wrote:
> Use RCU property of dcache to simplify locking in some places where we
> take d_parent and d_lock.
>
> Comment: don't need rcu_deref because we take the spinlock and recheck it.

Looks good other than one question below.

Thanx, Paul

> Signed-off-by: Nick Piggin <npiggin(a)suse.de>
> --
>
> Index: linux-2.6/fs/dcache.c
> ===================================================================
> --- linux-2.6.orig/fs/dcache.c
> +++ linux-2.6/fs/dcache.c
> @@ -311,23 +311,18 @@ struct dentry *dget_parent(struct dentry
> struct dentry *ret;
>
> repeat:
> - spin_lock(&dentry->d_lock);
> + rcu_read_lock();
> ret = dentry->d_parent;

Doesn't this need to be as follows?

ret = rcu_dereference(dentry)->d_parent;

Otherwise, couldn't we end up seeing pre-initialization value for
->d_parent for a newly inserted dentry?

> - if (!ret)
> - goto out;
> - if (dentry == ret) {
> - ret->d_count++;
> - goto out;
> - }
> - if (!spin_trylock(&ret->d_lock)) {
> - spin_unlock(&dentry->d_lock);
> + spin_lock(&ret->d_lock);

Once we do this, however, we are golden, at least for all dentry
fields protected by ->lock. This does assume that the compiler does not
speculate the fetch that initialized the argument dentry into the critical
section, which I would sure hope would be a reasonable assumption.

> + if (unlikely(ret != dentry->d_parent)) {
> + spin_unlock(&ret->d_lock);
> + rcu_read_unlock();
> goto repeat;
> }
> + rcu_read_unlock();
> BUG_ON(!ret->d_count);
> ret->d_count++;
> spin_unlock(&ret->d_lock);
> -out:
> - spin_unlock(&dentry->d_lock);
> return ret;
> }
> EXPORT_SYMBOL(dget_parent);
> @@ -601,14 +596,22 @@ static void prune_one_dentry(struct dent
> if (inode)
> spin_lock(&inode->i_lock);
> again:
> - spin_lock(&dentry->d_lock);
> - if (dentry->d_parent && dentry != dentry->d_parent) {
> - if (!spin_trylock(&dentry->d_parent->d_lock)) {
> - spin_unlock(&dentry->d_lock);
> + rcu_read_lock();
> + parent = dentry->d_parent;
> + if (parent) {
> + spin_lock(&parent->d_lock);
> + if (unlikely(parent != dentry->d_parent)) {
> + spin_unlock(&parent->d_lock);
> + rcu_read_unlock();
> goto again;
> }
> - parent = dentry->d_parent;
> - }
> + if (parent != dentry)
> + spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
> + else
> + parent = NULL;
> + } else
> + spin_lock(&dentry->d_lock);
> + rcu_read_unlock();
> dentry->d_count--;
> if (dentry->d_count) {
> if (parent)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nick Piggin on
Hi Paul,

Sorry I had left this in my postponed folder while rechecking your
questions and forgot about it :P


On Mon, Jun 28, 2010 at 02:50:13PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 24, 2010 at 01:02:36PM +1000, npiggin(a)suse.de wrote:
> > Use RCU property of dcache to simplify locking in some places where we
> > take d_parent and d_lock.
> >
> > Comment: don't need rcu_deref because we take the spinlock and recheck it.
>
> Looks good other than one question below.
>
> Thanx, Paul
>
> > Signed-off-by: Nick Piggin <npiggin(a)suse.de>
> > --
> >
> > Index: linux-2.6/fs/dcache.c
> > ===================================================================
> > --- linux-2.6.orig/fs/dcache.c
> > +++ linux-2.6/fs/dcache.c
> > @@ -311,23 +311,18 @@ struct dentry *dget_parent(struct dentry
> > struct dentry *ret;
> >
> > repeat:
> > - spin_lock(&dentry->d_lock);
> > + rcu_read_lock();
> > ret = dentry->d_parent;
>
> Doesn't this need to be as follows?
>
> ret = rcu_dereference(dentry)->d_parent;
>
> Otherwise, couldn't we end up seeing pre-initialization value for
> ->d_parent for a newly inserted dentry?

I don't think so. The child's dentry memory should be guaranteed to be
post-initialized at the point it is passed to dget_parent, becase we've
to have a stable refcount on it at that point. Ie. if it was pulled from
an RCU list, it should already have been rcu dereferenced by now.

So ->d_parent should be a valid pointer with lifetime guarantee provided
by RCU -- so enough to take the spinlock and recheck.

>
> > - if (!ret)
> > - goto out;
> > - if (dentry == ret) {
> > - ret->d_count++;
> > - goto out;
> > - }
> > - if (!spin_trylock(&ret->d_lock)) {
> > - spin_unlock(&dentry->d_lock);
> > + spin_lock(&ret->d_lock);
>
> Once we do this, however, we are golden, at least for all dentry
> fields protected by ->lock. This does assume that the compiler does not
> speculate the fetch that initialized the argument dentry into the critical
> section, which I would sure hope would be a reasonable assumption.

Yes I think the above fact that we have a "good" ref on the dentry
should prevent this.

Thanks,
Nick

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/