Re: [PATCH 04/11] vfs: check unlinked ancestors before mount

[Miklos Szeredi]

On Thu, Sep 05, 2013 at 02:23:25PM +0100, Al Viro wrote:
> On Thu, Sep 05, 2013 at 02:39:11PM +0200, Miklos Szeredi wrote:
> > +static bool __has_unlinked_ancestor(struct dentry *dentry)
> > +{
> > +	struct dentry *this;
> > +
> > +	for (this = dentry; !IS_ROOT(this); this = this->d_parent) {
> > +		int is_unhashed;
> > +
> > +		/* Need exclusion wrt. check_submounts_and_drop() */
> > +		spin_lock(&this->d_lock);
> > +		is_unhashed = d_unhashed(this);
> > +		spin_unlock(&this->d_lock);
> > +
> > +		if (is_unhashed)
> > +			return true;
> > +	}
> > +	return false;
> > +}
> 
> I still don't get it; why do you need to bother with early setting of
> DCACHE_MOUNTED?
> 
> You are grabbing rename_lock for write in d_set_mounted().  What kind of races
> with check for submounts are you worried about?  d_walk() will rescan
> everything if something grabs rename_lock for write while it had been running,
> so just fold the "have nothing in d_subdir" case of check_submounts_and_drop()
> into d_walk() and be done with that...  What's the problem with such
> variant?  AFAICS, all you need to care about is d_set_mounted() not getting
> between the scan for submounts and actual __d_drop() and your "finish"
> callback is called only after d_walk() having grabbed d_lock *and* rechecked
> rename_lock.

Okay, I get it.  So this should work:

int d_set_mounted(struct dentry *dentry)
{
	int ret = -ENOENT;

	write_seqlock(&rename_lock);
	if (!__has_unlinked_ancestor(dentry->d_parent)) {
		spin_lock(&dentry->d_lock);
		if (!d_unlinked(dentry)) {
			dentry->d_flags |= DCACHE_MOUNTED;
			ret = 0;
		}
		spin_unlock(&dentry->d_lock);
	}
	write_sequnlock(&rename_lock);
	return ret;
}

The __has_unlinked_ancestor(dentry->d_parent) will work if dentry is a root, but
maybe it would be clearer to add that IS_ROOT explicitly?

Thanks,
Miklos


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