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 12:13:42 +0800 Message-ID: <4A42F976.8020406@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> 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-out3.iinet.net.au ([203.59.1.148]:41683 "EHLO outbound.icp-qv1-irony-out3.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752224AbZFYENn (ORCPT ); Thu, 25 Jun 2009 00:13:43 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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? Ian