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
next prev parent 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.