Re: [PATCH 0/2] NFS: limit use of ACCESS cache for negative responses

[Trond Myklebust <trondmy@hammerspace.com>]

On Tue, 2022-05-17 at 10:40 +1000, NeilBrown wrote:
> On Tue, 17 May 2022, Trond Myklebust wrote:
> > On Tue, 2022-05-17 at 10:05 +1000, NeilBrown wrote:
> > > 
> > > Hi,
> > >  any thoughts on these patches?
> > 
> > 
> > To me, this problem is simply not worth breaking hot path
> > functionality
> > for. If the credential changes on the server, but not on the client
> > (so
> > that the cred cache comparison still matches), then why do we care?
> > 
> > IOW: I'm a NACK until convinced otherwise.
> 
> In what way is the hot path broken?  It only affect a permission test
> failure.  Why is that considered "hot path"??

It is a permission test that is critical for caching path resolution on
a per-user basis.

> 
> RFC 1813 says - for NFSv3 at least - 
> 
>       The information returned by the server in response to an
>       ACCESS call is not permanent. It was correct at the exact
>       time that the server performed the checks, but not
>       necessarily afterwards. The server can revoke access
>       permission at any time.
> 
> Clearly the server can allow allow access at any time.
> This seems to argue against caching - or at least against relying too
> heavily on the cache.
> 
> RFC 8881 has the same text for NFSv4.1 - section 18.1.4
> 
> "why do we care?" Because the server has changed to grant access, but
> the client is ignoring the possibility of that change - so the user
> is
> prevented from doing work.

The server enforces permissions in NFS. The client permissions checks
are performed in order to gate access to data that is already in cache.
NACK

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com