All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "anna@kernel.org" <anna@kernel.org>,
	"chuck.lever@oracle.com" <chuck.lever@oracle.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"bcodding@redhat.com" <bcodding@redhat.com>
Subject: Re: [PATCH] SUNRPC: Fix backchannel reply, again
Date: Tue, 18 Jun 2024 22:45:41 +0000	[thread overview]
Message-ID: <f4b5bb6c7c4322d87b09bb101b402e45d717fe57.camel@hammerspace.com> (raw)
In-Reply-To: <ZnHuoD3JrXk0ho8O@tissot.1015granger.net>

On Tue, 2024-06-18 at 16:31 -0400, Chuck Lever wrote:
> On Fri, Jun 14, 2024 at 10:18:52AM -0400, cel@kernel.org wrote:
> > From: Chuck Lever <chuck.lever@oracle.com>
> > 
> > I still see "RPC: Could not send backchannel reply error: -110"
> > quite often, along with slow-running tests. Debugging shows that
> > the
> > backchannel is still stumbling when it has to queue a callback
> > reply
> > on a busy transport.
> > 
> > Note that every one of these timeouts causes a connection loss by
> > virtue of the xprt_conditional_disconnect() call in that arm of
> > call_cb_transmit_status().
> > 
> > I found that setting to_maxval is necessary to get the RPC timeout
> > logic to behave whenever to_exponential is not set.
> > 
> > Fixes: 57331a59ac0d ("NFSv4.1: Use the nfs_client's rpc timeouts
> > for backchannel")
> > Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> > ---
> >  net/sunrpc/svc.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> > index 965a27806bfd..f4ddb2961042 100644
> > --- a/net/sunrpc/svc.c
> > +++ b/net/sunrpc/svc.c
> > @@ -1643,6 +1643,7 @@ void svc_process_bc(struct rpc_rqst *req,
> > struct svc_rqst *rqstp)
> >  		timeout.to_initval = req->rq_xprt->timeout-
> > >to_initval;
> >  		timeout.to_retries = req->rq_xprt->timeout-
> > >to_retries;
> >  	}
> > +	timeout.to_maxval = timeout.to_initval;
> >  	memcpy(&req->rq_snd_buf, &rqstp->rq_res, sizeof(req-
> > >rq_snd_buf));
> >  	task = rpc_run_bc_task(req, &timeout);
> >  
> > -- 
> > 2.45.1
> > 
> 
> Hi - would love to see this in 6.10-rc. Is there a chance that
> could happen?

Hmm... Can we please also set the remaining fields in timeout to 0?
Otherwise, we're still playing roulette with what actually ends up
happening in xprt_calc_majortimeo(). If to_increment happens to be
large enough, we could overflow and end up with a silly small timeout
value on a retry.


-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2024-06-18 22:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14 14:18 [PATCH] SUNRPC: Fix backchannel reply, again cel
2024-06-18 20:31 ` Chuck Lever
2024-06-18 22:45   ` Trond Myklebust [this message]
2024-06-18 21:17 ` Jeff Layton

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=f4b5bb6c7c4322d87b09bb101b402e45d717fe57.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=anna@kernel.org \
    --cc=bcodding@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.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.