Re: [for-6.11 PATCH 00/29] nfs/nfsd: add support for localio bypass

[Mike Snitzer <snitzer@kernel.org>]

On Mon, Jun 10, 2024 at 08:47:47AM -0400, Jeff Layton wrote:
> On Fri, 2024-06-07 at 10:26 -0400, Mike Snitzer wrote:
> > Hi,
> > 
> > This patch series rebases "localio" changes that Hammerspace (and
> > Primary Data before it) has been carrying since 2014. The reason they
> > weren't proposed for upstream inclusion until now was the handshake
> > for whether or not a client and server are local was brittle. Please
> > see the commit header of "nfs/localio: discontinue network address
> > based localio setup" (patch 20) for more context.
> > 
> > Aside from rebasing the original changes (patches 1 - 18) from a
> > 5.15.-130-stable kernel, my contribution to this series was to make
> > the localio handshake more robust. To do so a new LOCALIO protocol
> > extension has been added to both NFS v3 and v4. It follows the
> > well-worn pattern established by the ACL protocol extension.
> > 
> > These changes have proven stable against various test scenarios:
> > 1) client and server both on localhost (for both v3 and v4.2)
> > 2) various permutations of client and server support enablement for
> >    both local and remote client and server.
> > 3) client on host, server within a container (for both v3 and v4.2)
> > 
> > I've preserved all established author and Signed-off-by attribution
> > despite Andy, Peng and Jeff no longer working for Primary Data (or
> > Hammerspace). I've confirmed with Trond that its best to keep it all
> > despite those email addresses no longer being active. My Signed-off-
> > by
> > and that of reviewers and maintainer(s) to follow will build on the
> > established development provenance.
> >
> > I also made sure to preserve the original work done by others (rather
> > than fold changes that I add to this work, to avoid tainting the long
> > established development and sequence of changes).
> > 
> 
> Honestly, I don't give a fig about the historical changes here. I'd
> _much_ rather see a more logical folded patchset that avoids a lot of
> the "churn". Given the long timescale of this series, the history is
> just not terribly useful.

Fair, will do (and this answers the question I just asked in response
to a different patch).
 
> For instance, you're adding in the old network address tracking in the
> earlier patches and then remove that in patch #20, which just means I
> have to review a bunch of stuff that is ultimately going away. I'll
> still review the set you've posted, but I think folding down the
> changes would be best.

Yeah, I just wanted to not be excessive with folding patches -- purely
to preserve the evolution of these changes (given the different
authors, etc).  But I agree with you, and will sort it out for v2.

Mike