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, 26 Mar 2009 14:07:32 +0900 Message-ID: <49CB0D94.4040306@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> <49CAFC68.5000102@themaw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org, akpm@linux-foundation.org, Al Viro , Andreas Dilger , Yehuda Sadeh To: Sage Weil Return-path: Received: from outbound.icp-qv1-irony-out4.iinet.net.au ([203.59.1.150]:43182 "EHLO outbound.icp-qv1-irony-out4.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbZCZFHh (ORCPT ); Thu, 26 Mar 2009 01:07:37 -0400 In-Reply-To: <49CAFC68.5000102@themaw.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Ian Kent wrote: > Ian Kent wrote: >> Sage Weil wrote: >>> Would it be possible to avoid the upcall in revalidate, and instead fail >>> and let the subsequent lookup path do it? (I'm guessing the upcall >>> doesn't happen for _every_ revalidate?) > > snip ... > >> It was more than three years ago when I tried to make everything go >> through lookup so my memory is pretty unclear now. In the end I think >> there was one case in real_lookup() where the lookup was skipped, >> revalidate was called and failed but lookup wasn't then called again and >> I got an incorrect failure. AFAICR all other code paths that hold the >> mutex over lookup and revalidate perform the revalidate first and then >> the lookup if that fails, which avoids this case. > > I've managed to locate the work that I did on this (on an old machine I > left as it was for posterity). > > I haven't had a chance to look at what I did closely and a lot has > changed in autofs4 since. The one thing that I'm fairly sure I would > need to be able to make this work is the order of the calls in > real_lookup() to be revalidate then lookup. Would that work for > real_lookup() given that we hold the mutex now? DOH, which both patches together end up doing. > > In fact this might be an opportunity for me to clean up my sloppy > DCACHE_AUTOFS_PENDING handling by moving it all under the inode mutex. Unfortunately not, I still need to use this in the follow_link() method without the lock. Ian