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:
> 
> On Mon, Aug 3, 2026, at 12:23 PM, Jeff Layton wrote:
> > On Mon, 2026-08-03 at 12:04 -0400, Chuck Lever wrote:
> 
> > > 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.
> > 
> > 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.
> 
> 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.
> 
> 
> > > 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.
> > 
> > Does this mean you intend to drop dir delegation series again?
> 
> 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.
> 

Ok. I had an LLM draft up a propsed fix for this, but it's a bit
invasive and needs more testing. I'll see if I can put something
together in a follow-on series to the CB_NOTIFY patches.
-- 
Jeff Layton <[email protected]>