Message-ID: <0bd905c30a652d19404eef82b40f6b92987ca814.camel@redhat.com>
Subject: Re: Why doesn't NFSv3 implement LOOKUPP?
From:   Jeff Layton <jlayton@redhat.com>
To:     Yihao Wu <wuyihao@linux.alibaba.com>, linux-nfs@vger.kernel.org
Date:   Wed, 13 Feb 2019 06:50:16 -0500
In-Reply-To: <3dc67361-9c2f-d183-09e5-0a4d5c48d0f7@linux.alibaba.com>
References: <3dc67361-9c2f-d183-09e5-0a4d5c48d0f7@linux.alibaba.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Wed, 2019-02-13 at 16:41 +0800, Yihao Wu wrote:
> Hi all,
> 
> When looking into "Failures: generic/467" given by xfstests, I found that NFSv3
> didn't implement LOOKUPP. I know that this might be by design. But LOOKUPP was
> meant to replace ".." in NFSv3, right?
> 
> xfstests's generic/467 test case performs the following sequence of operations.
> 
> name_to_handle -> drop_caches -> open_by_handle
> 
> Dentry becomes disconnected due to drop_caches. NFSv3 doesn't support LOOKUPP.
> So when it performs open_by_handle to an directory, this test case fails.
> 
> I did some small experiment by implementing LOOKUPP for NFSv3. The way I tried
> is to merely pass ".." to nfs3_proc_lookup. And it seems to work. At least it's
> a workaround for xfstests.
> 
> I'm curious whether this sort of simulation of LOOKUPP will work or make sense.
> 
> Thanks,
> Yihao Wu

v3 was mostly designed with unix-like clients in mind. For v4, the spec
writers cast a wider net and decided not to put special meaning on
lookups of "." and "..", but they still needed a way to do a lookup of
"..".

The question is why you want to implement LOOKUPP in v3. Mostly we added
it to the client to support reexporting NFSv4 filesystems via NFSv3. Are
you looking to reexport v3 filesystems for some reason?
-- 
Jeff Layton <jlayton@redhat.com>