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@xxxxxxxxxxxxxxx
