Re: [PATCH v13 19/19] nfs: add FAQ section to Documentation/filesystems/nfs/localio.rst

[Trond Myklebust <trondmy@hammerspace.com>]

On Wed, 2024-08-28 at 07:49 +1000, NeilBrown wrote:
> On Tue, 27 Aug 2024, Trond Myklebust wrote:
> > > 
> > > 
> > > > On Aug 25, 2024, at 9:56 PM, NeilBrown <neilb@suse.de> wrote:
> > > > 
> > > > While I'm not advocating for an over-the-wire request to map a
> > > > filehandle to a struct nfsd_file*, I don't think you can
> > > > convincingly
> > > > argue against it without concrete performance measurements.
> > > 
> > 
> > What is the value of doing an open over the wire? What are you
> > trying
> > to accomplish that can't be accomplished without going over the
> > wire?
> 
> The advantage of going over the wire is avoiding code duplication.
> The cost is latency.  Obviously the goal of LOCALIO is to find those
> points where the latency saving justifies the code duplication.
> 
> When opening with AUTH_UNIX the code duplication to determine the
> correct credential is small and easy to review.  If we ever wanted to
> support KRB5 or TLS I would be a lot less comfortable about reviewing
> the code duplication.
> 
> So I think it is worth considering whether an over-the-wire open is
> really all that costly.  As I noted we already have an over-the-wire
> request at open time.  We could conceivably send the LOCALIO-OPEN
> request at the same time so as not to add latency.  We could receive
> the
> reply through the in-kernel backchannel so there is no RPC reply.
> 
> That might all be too complex and might not be justified.  My point
> is
> that I think the trade-offs are subtle and I think the FAQ answer
> cuts
> off an avenue that hasn't really been explored.
> 

So, your argument is that if there was a hypothetical situation where
we wanted to add krb5 or TLS support, then we'd have more code to
review?

The counter-argument would be that we've already established the right
of the client to do I/O to the file. This will already have been done
by an over-the-wire call to OPEN (NFSv4), ACCESS (NFSv3/NFSv4) or
CREATE (NFSv3). Those calls will have used krb5 and/or TLS to
authenticate the user. All that remains to be done is perform the I/O
that was authorised by those calls.

Furthermore, we'd already have established that the client and the
knfsd instance are running in the same kernel space on the same
hardware (whether real or virtualised). There is no chance for a bad
actor to compromise the one without also compromising the other.
However, let's assume that somehow is possible: How does throwing in an
on-the-wire protocol that is initiated by the one and interpreted by
the other going to help, given that both have access to the exact same
RPCSEC_GSS/TLS session and shared secret information via shared kernel
memory?

So again, what problem are you trying to fix?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com