On Sat, Jan 15, 2011 at 12:51 AM, Ian Kent <raven@xxxxxxxxxx> 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).
--
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
