Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel test robot	 <lkp@intel.com>
Subject: Re: [PATCH 1/2] nfsd: fix type mismatch and explain host-endian xdr buffer usage
Date: Mon, 03 Aug 2026 14:58:43 -0400	[thread overview]
Message-ID: <af9a4ca236e00df7e509e0112d88ef2cc41fa663.camel@kernel.org> (raw)
In-Reply-To: <848f6735-7b63-43d9-aadb-eeb1f0290d57@app.fastmail.com>

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 <jlayton@kernel.org>

  reply	other threads:[~2026-08-03 18:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 14:49 [PATCH 0/2] nfsd: fix up some sparse warnings Jeff Layton
2026-08-03 14:49 ` [PATCH 1/2] nfsd: fix type mismatch and explain host-endian xdr buffer usage Jeff Layton
2026-08-03 15:32   ` Chuck Lever
2026-08-03 15:43     ` Jeff Layton
2026-08-03 16:04       ` Chuck Lever
2026-08-03 16:23         ` Jeff Layton
2026-08-03 18:33           ` Chuck Lever
2026-08-03 18:58             ` Jeff Layton [this message]
2026-08-03 14:49 ` [PATCH 2/2] nfsd: fix nfserr type in nfsd_lookup_dentry() Jeff Layton
2026-08-03 15:16   ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af9a4ca236e00df7e509e0112d88ef2cc41fa663.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=cel@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox