Received-SPF: pass (google.com: domain of linux-nfs+bounces-386-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Benjamin Coddington <bcodding@redhat.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: spurious backchannel -ETIMEDOUT and reset on v6.7-rc1
Date: Thu, 07 Dec 2023 10:48:22 -0500
Message-ID: <F8E8E80E-C4FB-4243-8A18-A4D2F242B112@redhat.com>
In-Reply-To: <3B324BE9-874E-487E-B6E4-E83889B30803@redhat.com>
References: <3B324BE9-874E-487E-B6E4-E83889B30803@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On 7 Dec 2023, at 10:25, Benjamin Coddington wrote:

> Hey Trond,
>
> I've been noticing slower than usual xfstests, and in the logs:
>
>  "RPC: Could not send backchannel reply error: -110"
>
> Since "59464b262ff5 SUNRPC: SOFTCONN tasks should time out when on the
> sending list", some backchannel reqs will immediately reset the connection
> if they need to sleep on ->sending in xprt_reserve_xprt.
>
> I don't think we set up rq_timeout and rq_majortimeout for backchannel reqs,
> so they immediately fail with -ETIMEDOUT.
>
> I'm hunting around for the best fix, but maybe you've got one I can test.

Assuming we want backchannel reqs to actually check/timeout/reset, I think
its looking like we need to do a version of xprt_init_majortimeo() for every
xprt_get_bc_request()..

Ben