On Wed, 2020-10-07 at 14:05 -0400, bfields@xxxxxxxxxxxx wrote: > On Wed, Oct 07, 2020 at 05:29:26PM +0000, Trond Myklebust wrote: > > On Wed, 2020-10-07 at 13:15 -0400, Bruce Fields wrote: > > > Yeah, honestly I don't understand the details of that case > > > either. > > > > > > (There is one related thing I'm curious about, which is how close > > > we > > > are > > > to keeping clients in different containers completely separate > > > (which > > > we'd need, for example, if we were to ever permit unprivileged > > > nfs > > > mounts). It looks to me like as long as two network namespaces > > > use > > > different client identifiers, the client should keep different > > > state > > > for > > > them already? Or is there more to do there?) > > > > The containerised use case should already work. The containers have > > their own private uniquifiers, which can be changed > > via /sys/fs/nfs/net/nfs_client/identifier. > > I was just looking at that commit (bf11fbd20b3 "NFS: Add sysfs > support > for per-container identifier"), and I'm confused by it: it adds code > to > nfs/sysfs to get and set "identifier", but nothing anywhere that > actually uses the value. I can't figure out what I'm missing. > No, you're right. Something slipped under the radar there. The intention was that when it is set, the container-specific 'identifier' should replace the regular system-wide uniquifier. I thought I had merged patches for that, but apparently something got screwed up. Let me fix that up for 5.10... -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
