All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: NeilBrown <neil@brown.name>
Cc: Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	 Chuck Lever <chuck.lever@oracle.com>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>,  Tom Talpey <tom@talpey.com>,
	Mike Snitzer <snitzer@kernel.org>,
	linux-nfs@vger.kernel.org, 	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 1/2] sunrpc: delay pc_release callback until after sending a reply
Date: Thu, 03 Jul 2025 20:05:51 -0400	[thread overview]
Message-ID: <7ca38b49fcea9bc459c07accb3af64b790f6004b.camel@kernel.org> (raw)
In-Reply-To: <175158561386.565058.1936125782874530200@noble.neil.brown.name>

On Fri, 2025-07-04 at 09:33 +1000, NeilBrown wrote:
> On Fri, 04 Jul 2025, Jeff Layton wrote:
> > The server-side sunrpc code currently calls pc_release before sending
> > the reply. A later nfsd patch will change some pc_release callbacks to
> > do extra work to clean the pagecache. There is no need to delay sending
> > the reply for this, however.
> > 
> > Change svc_process and svc_process_bc to call pc_release after sending
> > the reply instead of before.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  net/sunrpc/svc.c | 19 +++++++++++++++----
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> > index b1fab3a6954437cf751e4725fa52cfc83eddf2ab..103bb6ba8e140fdccd6cab124e715caeb41bb445 100644
> > --- a/net/sunrpc/svc.c
> > +++ b/net/sunrpc/svc.c
> > @@ -1426,8 +1426,6 @@ svc_process_common(struct svc_rqst *rqstp)
> >  
> >  	/* Call the function that processes the request. */
> >  	rc = process.dispatch(rqstp);
> > -	if (procp->pc_release)
> > -		procp->pc_release(rqstp);
> >  	xdr_finish_decode(xdr);
> >  
> >  	if (!rc)
> > @@ -1526,6 +1524,14 @@ static void svc_drop(struct svc_rqst *rqstp)
> >  	trace_svc_drop(rqstp);
> >  }
> >  
> > +static void svc_release_rqst(struct svc_rqst *rqstp)
> > +{
> > +	const struct svc_procedure *procp = rqstp->rq_procinfo;
> > +
> > +	if (procp && procp->pc_release)
> > +		procp->pc_release(rqstp);
> > +}
> > +
> >  /**
> >   * svc_process - Execute one RPC transaction
> >   * @rqstp: RPC transaction context
> > @@ -1533,7 +1539,7 @@ static void svc_drop(struct svc_rqst *rqstp)
> >   */
> >  void svc_process(struct svc_rqst *rqstp)
> >  {
> > -	struct kvec		*resv = &rqstp->rq_res.head[0];
> > +	struct kvec			*resv = &rqstp->rq_res.head[0];
> 
> Commas and Tabs - you can never really have enough of them, can you?
> 

Not sure what happened there. I'll drop that hunk.

> >  	__be32 *p;
> >  
> >  #if IS_ENABLED(CONFIG_FAIL_SUNRPC)
> > @@ -1565,9 +1571,12 @@ void svc_process(struct svc_rqst *rqstp)
> >  	if (unlikely(*p != rpc_call))
> >  		goto out_baddir;
> >  
> > -	if (!svc_process_common(rqstp))
> > +	if (!svc_process_common(rqstp)) {
> > +		svc_release_rqst(rqstp);
> >  		goto out_drop;
> > +	}
> >  	svc_send(rqstp);
> > +	svc_release_rqst(rqstp);
> >  	return;
> 
> Should we, as a general rule, avoid calling any cleanup function more
> than once?  When tempted, we DEFINE_FREE() a cleanup function and
> declare the variable appropriately.

I'm not opposed to that. I think that change probably deserves a
separate patch.

> Though in this case it might be easier to:
> 
>   if (svc_process_common(rqstp))
>        svc_send(rqstp);
>   else
>        svc_drop(rqstp);
>   svc_rlease_rqst(rqstp);
>   return;
> 

There is another place that does a "goto out_drop in that function. I'm
not sure changing that would improve things, but I'll see how it looks.

> svc_process_bc() is a little more awkward.
> 

Definitely.

> But in general, delaying the release function until after the send seems
> sound, and this patches appears to do it corretly.
> 
> Reviewed-by: NeilBrown <neil@brown.name>
> 
> NeilBrown

Thanks for the review!
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2025-07-04  0:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 19:53 [PATCH RFC 0/2] nfsd: issue POSIX_FADV_DONTNEED after READ/WRITE/COMMIT Jeff Layton
2025-07-03 19:53 ` [PATCH RFC 1/2] sunrpc: delay pc_release callback until after sending a reply Jeff Layton
2025-07-03 23:33   ` NeilBrown
2025-07-04  0:05     ` Jeff Layton [this message]
2025-07-03 19:53 ` [PATCH RFC 2/2] nfsd: call generic_fadvise after v3 READ, stable WRITE or COMMIT Jeff Layton
2025-07-03 20:07   ` Chuck Lever
2025-07-08 14:34     ` Jeff Layton
2025-07-08 21:12       ` Mike Snitzer
2025-07-08 21:07     ` Mike Snitzer
2025-07-03 23:44   ` NeilBrown
2025-07-03 23:49     ` Jeff Layton
2025-07-04  7:26     ` NeilBrown
2025-07-05 11:21       ` Jeff Layton
2025-07-03 23:16 ` [PATCH RFC 0/2] nfsd: issue POSIX_FADV_DONTNEED after READ/WRITE/COMMIT NeilBrown
2025-07-03 23:28   ` Chuck Lever
2025-07-04  7:34     ` NeilBrown
2025-07-05 11:32   ` Jeff Layton
2025-07-10  8:00     ` Christoph Hellwig

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=7ca38b49fcea9bc459c07accb3af64b790f6004b.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=anna@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=snitzer@kernel.org \
    --cc=tom@talpey.com \
    --cc=trondmy@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.