On Wed, 28 Aug 2024, Trond Myklebust wrote: > 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. The other thing that remains is to get the correct 'struct cred *' to store in ->f_cred (or to use for lookup in the nfsd filecache). > > 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? Conversely: what exactly is this FAQ entry trying to argue against? My current immediate goal is for the FAQ to be useful. It mostly is, but this one question/answer isn't clear to me. Thanks, NeilBrown
