On Wed, Oct 07, 2020 at 07:11:49PM +0000, Trond Myklebust wrote: > 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... Great, thanks. --b.
