Received-SPF: pass (google.com: domain of linux-nfs+bounces-903-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Benjamin Coddington <bcodding@redhat.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@kernel.org>,
 Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: hangs during fstests testing with TLS
Date: Wed, 03 Jan 2024 15:16:28 -0500
Message-ID: <AB421B16-F1FD-414C-A9BE-652D868F03A9@redhat.com>
In-Reply-To: <D1091C94-9F23-47E9-A9CF-31CCEFE5EF8A@oracle.com>
References: <117352d5dc94d8f31bc6770e4bbb93a357982a93.camel@kernel.org>
 <ABBA5E37-2E13-4603-A79C-F9B9B8488AE3@redhat.com>
 <D1091C94-9F23-47E9-A9CF-31CCEFE5EF8A@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3 Jan 2024, at 14:12, Chuck Lever III wrote:

>> On Jan 3, 2024, at 1:47=E2=80=AFPM, Benjamin Coddington <bcodding@redh=
at.com> wrote:
>>
>> This looks like it started out as the problem I've been sending patche=
s to
>> fix on 6.7, latest here:
>> https://lore.kernel.org/linux-nfs/e28038fba1243f00b0dd66b7c5296a1e1816=
45ea.1702496910.git.bcodding@redhat.com/
>>
>> .. however whenever I encounter the issue, the client reconnects the
>> transport again - so I think there might be an additional problem here=
=2E
>
> I'm looking at the same problem as you, Ben. It doesn't seem to be
> similar to what Jeff reports.
>
> But I'm wondering if gerry-rigging the timeouts is the right answer
> for backchannel replies. The problem, fundamentally, is that when a
> forechannel RPC task holds the transport lock, the backchannel's reply
> transmit path thinks that means the transport connection is down and
> triggers a transport disconnect.

Why shouldn't backchannel replies have normal timeout values?

> The use of ETIMEDOUT in call_bc_transmit_status() is... not especially
> clear.

Seems like it should mean that the reply couldn't be sent within (what
should be) the timeout values for the client's state management transport=
=2E

I'm glad you're seeing this problem too.  I was worried that something wa=
s
seriously different about my test setup.

Ben