From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount Date: Fri, 30 Aug 2013 14:22:58 -0700 Message-ID: References: <52200DAE.2020303@hp.com> <5220E56A.80603@hp.com> <5220F090.5050908@hp.com> <5220FD51.2010709@hp.com> <20130830205404.GF13318@ZenIV.linux.org.uk> <52210A55.8010308@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Al Viro , Ingo Molnar , Benjamin Herrenschmidt , Jeff Layton , Miklos Szeredi , Ingo Molnar , Thomas Gleixner , linux-fsdevel , Linux Kernel Mailing List , Peter Zijlstra , Steven Rostedt , Andi Kleen , "Chandramouleeswaran, Aswin" , "Norton, Scott J" To: Waiman Long Return-path: In-Reply-To: <52210A55.8010308@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Aug 30, 2013 at 2:10 PM, Waiman Long wrote: > > Actually, prepend_path() was called with rename_lock taken. So d_move() > couldn't be run at the same time. Am I right? Al was discussing the case I mentioned: getting rid of that lock entirely, running it all just under RCU, and then just checking the rename sequence count around it all and retrying if required. It would have the advantage of not only not having to get the lock, but by doing it as an RCU walk, we would avoid all the nasty reference counting costs too. We wouldn't even need to get refcounts on the root/pwd entries (which currently cost us quite a bit), since we could just check the sequence number in "struct fs_struct" too. That also gets rid of the necessity for the fs->lock spinlock. You do have to be a bit careful when following the dentry pointers under RCU (and you cannot just do a "memcpy()" on the name, as Al points out), but it really doesn't look nasty. It just looks "you have to be careful". Linus