[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71ddafd443a0e13f79cea09ba2b3ac4f106163ce.camel@kernel.org>
Date: Tue, 13 Jan 2026 14:31:55 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Chuck Lever <cel@...nel.org>, Chuck Lever <chuck.lever@...cle.com>,
NeilBrown <neil@...wn.name>, Olga Kornievskaia <okorniev@...hat.com>, Dai
Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, Trond Myklebust
<trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>
Cc: Benjamin Coddington <bcodding@...merspace.com>,
linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] nfsd/sunrpc: add svc_rqst->rq_private pointer and
remove rq_lease_breaker
On Tue, 2026-01-13 at 14:21 -0500, Chuck Lever wrote:
>
> On Tue, Jan 13, 2026, at 1:37 PM, Jeff Layton wrote:
> > diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> > index eee8c3f4a251a3fae6e41679de0ec34c76caf198..8ce366c9e49220e8baf475c2e5f3424fedc1cec1 100644
> > --- a/fs/nfsd/nfssvc.c
> > +++ b/fs/nfsd/nfssvc.c
> > @@ -900,6 +900,7 @@ nfsd(void *vrqstp)
> > struct svc_xprt *perm_sock = list_entry(rqstp->rq_server->sv_permsocks.next, typeof(struct svc_xprt), xpt_list);
> > struct net *net = perm_sock->xpt_net;
> > struct nfsd_net *nn = net_generic(net, nfsd_net_id);
> > + struct nfsd_thread_local_info ntli = { };
> > bool have_mutex = false;
> >
> > /* At this point, the thread shares current->fs
> > @@ -914,6 +915,8 @@ nfsd(void *vrqstp)
> >
> > set_freezable();
> >
> > + rqstp->rq_private = &ntli;
> > +
> > /*
> > * The main request loop
> > */
>
> Thanks for tackling this one. Nits below...
>
> This assumes sizeof(structure nfsd_thread_local_info) will always
> be small enough that it is reasonable to keep on the stack. I
> can't say that would be a good bet in the long run.
>
> And we don't need the perfect reliability of not doing a dynamic
> allocation here. If kmalloc(sizeof(struct nfsd_thread_local_info))
> fails, the thread exits immediately, no harm.
>
Not sure how much space Ben will need (if any).
We certainly could have nfsd allocate this separately. I didn't see the
point for something that is only a few bytes though.
> Also, scatter-gather lists could not be stored directly in this
> object because it is on the stack. If Ben wanted to stick a
> 32-byte buffer in struct nfsd_thread_local_info to be used with
> the crypto API, it would have to be a pointer to it, not the
> buffer itself.
>
*nod*
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists