From mboxrd@z Thu Jan  1 00:00:00 1970
From: hooanon05@yahoo.co.jp
Subject: Re: Q: NFSD readdir in linux-2.6.28
Date: Fri, 20 Mar 2009 00:34:50 +0900
Message-ID: <8913.1237476890@jrobl>
References: <8036.1237474444@jrobl> <1237475837.16359.106.camel@macbook.infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
To: David Woodhouse <dwmw2@infradead.org>
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1756864AbZCSPfy@vger.kernel.org>
In-Reply-To: <1237475837.16359.106.camel@macbook.infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org


David Woodhouse:
> Yes, well spotted. It didn't matter when the buffered readdir() was
> purely internal to XFS, because it didn't matter there that we called
> ->lookup() without i_mutex set. But now we're exposing arbitrary file
> systems to it, we need to make sure we follow the locking rules. 
> 
> I _think_ it's sufficient to make the affected callers of
> lookup_one_len() lock the parent's i_mutex for themselves before calling
> it. I'll take a closer look...

If you remember why you discarded the FS_NO_LOOKUP_IN_READDIR flag
approach, please let me know. URL or something is enough.

Thanx
J. R. Okajima