From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH 09/18] autofs4: Add d_manage() dentry operation [ver #4] Date: Fri, 14 Jan 2011 15:35:54 +0000 Message-ID: <5326.1295019354@redhat.com> References: <20110113215359.19406.37232.stgit@warthog.procyon.org.uk> <20110113215448.19406.58770.stgit@warthog.procyon.org.uk> <1295013099.2794.6.camel@perseus> Cc: dhowells@redhat.com, Ian Kent , viro@zeniv.linux.org.uk, npiggin@kernel.dk, autofs@linux.kernel.org, linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16522 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757712Ab1ANPgI (ORCPT ); Fri, 14 Jan 2011 10:36:08 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Nick Piggin wrote: > > On Thu, 2011-01-13 at 21:54 +0000, David Howells wrote: > >> From: Ian Kent > >> + //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