> On Jun 19, 2024, at 1:30 AM, NeilBrown <neilb@xxxxxxx> wrote: > > 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. I agree. > 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. Since this is Linux-to-Linux, interop is not a concern. But there is value in squatting on the program number to ensure no-one else will use it (even by another Linux- only consumer). Mike, IMO you should look into reserving the program number properly. > 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 >> >> > -- Chuck Lever
