Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755029Ab3H3VXA (ORCPT ); Fri, 30 Aug 2013 17:23:00 -0400 Received: from mail-vb0-f45.google.com ([209.85.212.45]:55314 "EHLO mail-vb0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751791Ab3H3VW7 (ORCPT ); Fri, 30 Aug 2013 17:22:59 -0400 MIME-Version: 1.0 In-Reply-To: <52210A55.8010308@hp.com> 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> Date: Fri, 30 Aug 2013 14:22:58 -0700 X-Google-Sender-Auth: RRvkY7bqQQaS5-ySZt6CSfxO2co Message-ID: Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount From: Linus Torvalds To: Waiman Long 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1278 Lines: 27 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/