Re: [PATCH 1/2] nfsd: fix type mismatch and explain host-endian xdr buffer usage

On Mon, 2026-08-03 at 14:33 -0400, Chuck Lever wrote:
>=20
> On Mon, Aug 3, 2026, at 12:23 PM, Jeff Layton wrote:
> > On Mon, 2026-08-03 at 12:04 -0400, Chuck Lever wrote:
>=20
> > > Number 3: Yes, we have a sordid history of grabbing a piece of
> > > the xdr_buf's tail iov for temporary storage. That doesn't make
> > > it wise to do, and assumes behavior about that buffer that is
> > > not guaranteed by sunrpc's API contracts. That makes life hard
> > > when future changes need to change that buffer to, say, a page
> > > rather than kmalloc'd memory. Or when I want to convert this
> > > code to use xdrgen instead of hand-rolled encoding.
> >=20
> > I had no idea this practice was suddenly forbidden. That has certainly
> > not been communicated to me in any of the previous review rounds over
> > the last couple of years.
>=20
> I've been removing instances of this anti-pattern for some time. I
> haven't seen new code (until now) that tries to do this. It simply
> hasn't come up recently and I typically don't look closely for it.
>=20
>=20
> > > So what you've done is fine for operational prototype code, but
> > > not something we can carry forward as production code. The sparse
> > > warning is a canary, it's not the actual structural problem.
> >=20
> > Does this mean you intend to drop dir delegation series again?
>=20
> No. It's deep in nfsd-next now, and this is a long-term issue, not
> an immediate on-the-wire behavioral problem or a vulnerability.
>=20

Ok, I'll send a separate series on top of this that should address your
concerns. We may be able to get away with stack allocations for some of
these, and for the others we can just add a separate kmalloc'ed set of
buffers or something.

That'll probably be v7.4 material at the soonest though.
--=20
Jeff Layton <[email protected]>