From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Kent Subject: Re: [PATCH 1/2] vfs: make real_lookup do dentry revalidation with i_mutex held Date: Thu, 25 Jun 2009 13:52:32 +0800 Message-ID: <4A4310A0.3040407@themaw.net> References: <1237493790-5665-1-git-send-email-sage@newdream.net> <49C85E3E.7030505@themaw.net> <49C85F0A.9030409@themaw.net> <49C9CA5A.5080809@themaw.net> <49CA579B.5080307@themaw.net> <49CAE3DB.3030909@themaw.net> <1238063926.23853.15.camel@zeus.themaw.net> <49D56DD5.80707@themaw.net> <4A4023CF.7040203@themaw.net> <4A418F5D.3020906@themaw.net> <4A41EF2B.606@themaw.net> <4A42F976.8020406@themaw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel , Christoph Hellwig , akpm@linux-foundation.org, Al Viro , Yehuda Sadeh , "H. Peter Anvin" To: Sage Weil Return-path: Received: from outbound.icp-qv1-irony-out4.iinet.net.au ([203.59.1.150]:64345 "EHLO outbound.icp-qv1-irony-out4.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751084AbZFYFwc (ORCPT ); Thu, 25 Jun 2009 01:52:32 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Sage Weil wrote: > On Thu, 25 Jun 2009, Ian Kent wrote: >> Sage Weil wrote: >>>> There are several cases I need to deal with, apart from path walks >>>> initiated by the daemon which don't cause any call backs, and so are >>>> largely handled by trivially returning success. The cases are, an >>>> expiring dentry that will go away which ->lookup() can't yet handle, an >>>> expiring dentry that won't go away which ->lookup() should be able to >>>> handle already, and a straight out mount request which ->lookup() should >>>> also be able to handle. The tail end of the expire cases can progress >>>> concurrently with a mount, which is further complicated by the two cases >>>> of going away or not, so it's all a bit tricky. >>> It sounds to me like revalidate should only return success in the trivial, >>> non-blocking case. And the ->lookup() should be able to handle all >>> (other) cases. I.e., things should still work correctly (perhaps more >>> slowly) without any d_revalidate() at all. (It still looks like the main >>> change needed is for lookup to use d_obtain_alias, instead of returning >>> NULL unconditionally...) >> How so? >> >> I don't understand how d_obtain_alias() can help in this situation. >> Can you elaborate please? > > Well, as you noticed I misread lookup (it doesn't always return NULL). I > originally just meant that lookup needs to return an existing dentry if > there is one (found via autofs4_lookup_active?), since now it may not be > able to count on revalidate blocking on the hashed one if it's not usable > yet. It looks like it's tracking mounts by dentry, not inode, so > d_obtain_alias isn't terribly helpful. Yep, that's right. It gets better too. Previously, in lookup, the call back was unconditional, but to avoid mount storms from colour ls, now it isn't. Except for this I could just rely on ->lookup() using a new dentry and not add the revalidating dentry to the active list. > > As you can see I haven't spent much time looking at this code. :) I'm > happy to do so, though, or spend some time testing to get this resolved.. > just let me know how I can help. You can't just yet as it's completely different from the original patch. Let me get this to a sensible point then we can both go over it in detail. Ian