On Tue, 2022-02-08 at 10:23 -0500, Benjamin Coddington wrote: > On 8 Feb 2022, at 9:42, Chuck Lever III wrote: > > > > On Feb 8, 2022, at 9:29 AM, Benjamin Coddington > > > <bcodding@xxxxxxxxxx> > > > wrote: > > > > > > On 8 Feb 2022, at 8:45, Trond Myklebust wrote: > > > > > > > > Can't we just uniquify the namespaced NFS client ourselves, > > > > > while > > > > > still > > > > > exposing /sys/fs/nfs/net/nfs_client/identifier within the > > > > > namespace? > > > > > That > > > > > way if someone want to run udev or use their own method of > > > > > persistent > > > > > id > > > > > its available to them within the container so they can. Then > > > > > we > > > > > can > > > > > move > > > > > forward because the problem of distinguishing clients between > > > > > the > > > > > host > > > > > and > > > > > netns is automagically solved. > > > > > > > > That could be done. > > > > > > Ok, I'm eyeballing a sha1 of the init namespace uniquifier and > > > peernet2id_alloc(new_net, init_net).. but means the NFS client > > > would > > > grow a > > > dependency on CRYPTO and CRYPTO_SHA1. > > > > Or you could use siphash instead of SHA-1. > > > > I don't think we should be adding any more SHA-1 to the kernel -- > > it's deprecated for good reasons. > > Thanks! Siphash is nicer too. :) > > peernet2id_alloc() is not designed for this. It appears to use idr_alloc(), which means it will reuse values frequently. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
