Re: [PATCH v5 00/19] nfs/nfsd: add support for localio

[Mike Snitzer <snitzer@kernel.org>]

On Wed, Jun 19, 2024 at 05:10:10PM +1000, NeilBrown wrote:
> On Wed, 19 Jun 2024, Christoph Hellwig wrote:
> > What happened to the requirement that all protocol extensions added
> > to Linux need to be standardized in IETF RFCs?
> > 
> > 
> 
> Is that requirement documented somewhere?  Not that I doubt it, but it
> would be nice to know where it is explicit.  I couldn't quickly find
> anything in Documentation/
> 
> Can we get by without the LOCALIO protocol?
> 
> For NFSv4.1 we could use the server_owner4 returned by EXCHANGE_ID.  It
> is explicitly documented as being usable to determine if two servers are
> the same.

My first approach was to (ab)use EXCHANGE_ID. It worked, but it
required exporting a symbol to query the hash table local to
nfs4state, etc.  It wasn't very clean.. could it have been made
clean?: I guess... but in the end I elected to solve both v3 and v4.x in
the same way using LOCALIO protocol.

> For NFSv4.0 ... I don't think we should encourage that to be used.
> 
> For NFSv3 it is harder.  I'm not as ready to deprecate it as I am for
> 4.0.  There is nothing in NFSv3 or MOUNT or NLM that is comparable to
> server_owner4.  If krb5 was used there would probably be a server
> identity in there that could be used.
> I think the server could theoretically return an AUTH_SYS verifier in
> each RPC reply and that could be used to identify the server.  I'm not
> sure that is a good idea though.
> 
> Going through the IETF process for something that is entirely private to
> Linux seems a bit more than should be necessary..

I have to believe Christoph didn't appreciate this LOCALIO protocol is
an entirely private implementation detail to Linux (that allows client
and server handshake).  I've clarified that in Documentation (for v6).

Mike