Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: Lookup revalidation for OPEN_CLAIM_FH
Date:   Thu, 16 Jan 2020 11:21:35 -0500
Message-ID: <843EF573-3305-4490-B084-827F9FB87077@redhat.com>
In-Reply-To: <3a91fb298d29c17c76e2bce1a190110cd6fe72c0.camel@hammerspace.com>
References: <31B20BC3-A089-47F9-9821-7A3543FF7413@redhat.com>
 <7eae4162d7c8a85bbb7fddab3a818472ec2ebc54.camel@hammerspace.com>
 <C69931E7-7465-4662-91AC-C74609A4CDB2@redhat.com>
 <3a91fb298d29c17c76e2bce1a190110cd6fe72c0.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On 16 Jan 2020, at 10:38, Trond Myklebust wrote:

> On Thu, 2020-01-16 at 10:13 -0500, Benjamin Coddington wrote:
>> On 16 Jan 2020, at 9:35, Trond Myklebust wrote:
>
> nfs_file_open() is completely the wrong place to perform a lookup. Its
> purpose in the VFS is to allow the filesystem to set up state *after*
> we've already looked up the dentry, revalidated it and therefore
> decided which file to open.
> The NFSv4.0 behaviour of performing a new lookup is actually the
> aberration here, and is due to the fact that it does not have an open-
> by-filehandle operation, so we have no alternative.

Ok, that makes good sense to me.

> As I said, if you want stronger semantics, there are lookupcache mount
> options that allow you to tune things. I therefore see no valid reason
> to change the existing behaviour, which also matches that of older NFS
> versions (i.e. v3 and v2).

Thanks for the discussion.  Your point above about v4.0 CLAIM_NULL actually
doing another lookup after we already did a lookup throws things in sharp
relief.

Ben