On Wed, Mar 03, 2010 at 06:35:55PM +0100, Miklos Szeredi wrote:
> On Tue, 2 Mar 2010, Valerie Aurora wrote:
> > +/*
> > + * This must be called after __d_drop_unions() without holding any locks.
> > + * Note: The dentry might still be reachable via a lookup but at that time it
> > + * already a negative dentry. Otherwise it would be unhashed. The union_mount
> > + * structure itself is still reachable through mnt->mnt_unions (which we
> > + * protect against with union_lock).
> > + *
> > + * We were worried about a recursive dput() call through:
> > + *
> > + * dput()->d_kill()->shrink_d_unions()->union_put()->dput()
> > + *
> > + * But this path can only be reached if the dentry is unhashed when we
> > + * enter the first dput(), and it can only be unhashed if it was
> > + * rmdir()'d, and d_delete() calls shrink_d_unions() for us.
> > + */
> > +void shrink_d_unions(struct dentry *dentry)
> > +{
> > + struct union_mount *this, *next;
> > +
> > +repeat:
> > + spin_lock(&union_lock);
> > + list_for_each_entry_safe(this, next, &dentry->d_unions, u_unions) {
> > + BUG_ON(!hlist_unhashed(&this->u_hash));
> > + BUG_ON(!hlist_unhashed(&this->u_rhash));
> > + list_del(&this->u_unions);
> > + this->u_next.dentry->d_unionized--;
> > + spin_unlock(&union_lock);
> > + union_put(this);
> > + goto repeat;
>
> This loop is weird. That list_for_each_entry_safe is just used to
> initialize "this", since it unconditionally restarts from the
> beginning.
This loop is definitely weird, but the alternative is so simple
(replace the goto with a spin_lock()) that I suspect Jan had a reason
to write it this way. Jan, do you recall?
Unfortunately it has not been tested on more than one element in the
list (although multiple layers now seem a possibility with the current
code).
-VAL
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
