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@xxxxxxx> 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@xxxxxxxxxxxxxxx
