From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock Date: Sat, 7 Sep 2013 01:00:44 +0100 Message-ID: <20130907000044.GX13318@ZenIV.linux.org.uk> References: <1378483738-10129-1-git-send-email-Waiman.Long@hp.com> <1378483738-10129-2-git-send-email-Waiman.Long@hp.com> <20130906210546.GW13318@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Waiman Long , linux-fsdevel , Linux Kernel Mailing List , "Chandramouleeswaran, Aswin" , "Norton, Scott J" , George Spelvin , John Stoffel To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Sep 06, 2013 at 02:48:32PM -0700, Linus Torvalds wrote: > On Fri, Sep 6, 2013 at 2:05 PM, Al Viro wrote: > > > > I can take that, but I'm really not convinced that we need writer lock > > there at all. After all, if we really can get livelocks on that one, > > we would be getting them on d_lookup()... > > d_lookup() does a _single_ path component. That's a *big* difference. > > Sure, the hash chain that d_lookup() (well, __d_lookup()) ends up > walking is a bit more complicated than just following the dentry > parent pointer, but that's much harder to trigger than just creating a > really deep directory structure of single-letter nested directories, > and then doing a "getcwd()" that walks 1024+ parents, while another > thread is looping renaming things.. > > So I personally do feel a lot safer with the fallback to write locking here. > > Especially since it's pretty simple, so there isn't really much downside. Er... what will happen if you have done just what you've described and have a process call d_lookup()?