On Wed, 19 Jun 2024, Mike Snitzer wrote: > LOCALIOPROC_GETUUID allows client to discover server's uuid. > > nfs_local_probe() will retrieve server's uuid via LOCALIO protocol and > verify the server with that uuid it is known to be local. This ensures > client and server 1: support localio 2: are local to each other. > > While doing so, factor out nfs_init_localioclient() so it is used by > both nfs3client.c and nfs4client.c > > Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx> > --- .. > > +#define NFS_LOCALIO_PROGRAM 100229 According to RFC5531, this number is reserved for "metad". It might be best not to use it. That RFC says that assigning numbers isn't a job for IETF standard-track and handed the job over to IANA. IANA... https://www.iana.org/assignments/sun-rpc-numbers/sun-rpc-numbers.xhtml thinks SUN rpc numbers are obsolete. So maybe nobody cares. I would feel most comfortable allocating a number from the range: 0x20000000 - 0x3fffffff Defined by local administrator (some blocks assigned here) and maybe make it configurable by a module parameter just to be on the safe side (overkill??) We could try registering with lanana.org (The Linux Assigned Names And Numbers Authority) but I wouldn't be surprised if that went nowhere. While this might not matter in practice, I think we should appear to be doing the right thing. NeilBrown > +#define LOCALIOPROC_NULL 0 > +#define LOCALIOPROC_GETUUID 1 > + > #define NFS_PIPE_DIRNAME "nfs" > > /* > -- > 2.44.0 > >
