From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH v3 24/25] sunrpc: Change how dentry's d_lock field is accessed Date: Thu, 4 Jul 2013 05:20:34 +0100 Message-ID: <20130704042034.GM4165@ZenIV.linux.org.uk> References: <1372883132-23410-1-git-send-email-Waiman.Long@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeff Layton , Miklos Szeredi , Ingo Molnar , Thomas Gleixner , Trond Myklebust , "J. Bruce Fields" , "David S. Miller" , linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra , Steven Rostedt , Linus Torvalds , Benjamin Herrenschmidt , Andi Kleen , "Chandramouleeswaran, Aswin" , "Norton, Scott J" To: Waiman Long Return-path: Content-Disposition: inline In-Reply-To: <1372883132-23410-1-git-send-email-Waiman.Long@hp.com> Sender: netdev-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jul 03, 2013 at 04:25:32PM -0400, Waiman Long wrote: > There is no change in logic and everything should just work. > - spin_lock(&file->f_path.dentry->d_lock); > + d_lock(file->f_path.dentry); > if (!d_unhashed(file->f_path.dentry)) > clnt = RPC_I(inode)->private; > if (clnt != NULL && atomic_inc_not_zero(&clnt->cl_count)) { > - spin_unlock(&file->f_path.dentry->d_lock); > + d_unlock(file->f_path.dentry); Could somebody explain WTF is being protected here? It's not ->private - that gets set (and, more importantly, cleared) without ->d_lock in sight. Trond, that seems to be your code from about three years ago (introduced in "SUNRPC: Fix a race in rpc_info_open"). What's going on there?