Nick Piggin <npiggin@xxxxxxxxx> wrote:
> > On Thu, 2011-01-13 at 21:54 +0000, David Howells wrote:
> >> From: Ian Kent <raven@xxxxxxxxxx>
> >> + //spin_lock(&dcache_lock); /////////////// JUST DELETE THIS LOCK?
> >> + if (!d_mountpoint(dentry) && list_empty(&dentry->d_subdirs)) {
> >> + spin_lock(&dentry->d_lock);
> >> + if (!(dentry->d_flags & DCACHE_MANAGE_TRANSIT) &&
> >> + (dentry->d_flags & DCACHE_NEED_AUTOMOUNT))
> >> + __managed_dentry_set_transit(path->dentry);
> >> + spin_unlock(&dentry->d_lock);
> >> + }
> >> + //spin_unlock(&dcache_lock);
> >
> > In this case I think the dcache_lock needs to be deleted and the d_lock
> > moved out of the if to protect the d_subdirs access.
>
> Right. If you follow the vfs-scale-working git branch series of
> patches leading up to dcache_lock removal, it gives a pretty
> good template of how to convert old dcache_lock using code
> to new locking.
>
> Although you can also just look at locking in fs/dcache.c and
> convert code from that.
>
> Any time you are dealing with just a *single* dentry, then
> ->d_lock would be enough to replace dcache_lock (it
> actually protects more than dcache_lock alone did).
Does it make sense to leave the lock where it is and repeat the outer test
after we've taken the lock?
David
--
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
