From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: Q: NFSD readdir in linux-2.6.28 Date: Thu, 19 Mar 2009 15:51:52 +0000 Message-ID: <1237477912.16359.109.camel@macbook.infradead.org> References: <8036.1237474444@jrobl> <1237475837.16359.106.camel@macbook.infradead.org> <8913.1237476890@jrobl> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Al Viro , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" To: hooanon05@yahoo.co.jp Return-path: In-Reply-To: <8913.1237476890@jrobl> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2009-03-20 at 00:34 +0900, hooanon05@yahoo.co.jp wrote: > If you remember why you discarded the FS_NO_LOOKUP_IN_READDIR flag > approach, please let me know. URL or something is enough. I was just lamenting that decision. I think someone persuaded me that the extra complexity wasn't worth it, and that we should just do it unconditionally. One option would be to restore the FS_NO_LOOKUP_IN_READDIR flag, and document that it means that your ->lookup is called _without_ i_mutex held. That would actually be OK in all cases that need the flag, I believe (since the whole point in those cases is that they have their _own_ locking which is why we did it in the first place). -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation