Received-SPF: pass (google.com: domain of linux-nfs+bounces-924-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
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: Thu, 04 Jan 2024 07:22:18 -0500
Message-ID: <8C3DFB5D-B967-4D59-BFC5-7B25315DB9AB@redhat.com>
In-Reply-To: <DC58D77B-FC07-4B96-88A8-67F9ECDFD0CE@oracle.com>
References: <117352d5dc94d8f31bc6770e4bbb93a357982a93.camel@kernel.org>
 <ABBA5E37-2E13-4603-A79C-F9B9B8488AE3@redhat.com>
 <D1091C94-9F23-47E9-A9CF-31CCEFE5EF8A@oracle.com>
 <AB421B16-F1FD-414C-A9BE-652D868F03A9@redhat.com>
 <DC58D77B-FC07-4B96-88A8-67F9ECDFD0CE@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 16:46, Chuck Lever III wrote:

>> On Jan 3, 2024, at 3:16=E2=80=AFPM, Benjamin Coddington <bcodding@redh=
at.com> wrote:
>>
>> On 3 Jan 2024, at 14:12, Chuck Lever III wrote:
>>
>>>> On Jan 3, 2024, at 1:47=E2=80=AFPM, Benjamin Coddington <bcodding@re=
dhat.com> wrote:
>>>>
>>>> This looks like it started out as the problem I've been sending patc=
hes to
>>>> fix on 6.7, latest here:
>>>> https://lore.kernel.org/linux-nfs/e28038fba1243f00b0dd66b7c5296a1e18=
1645ea.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 he=
re.
>>>
>>> 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 repl=
y
>>> transmit path thinks that means the transport connection is down and
>>> triggers a transport disconnect.
>>
>> Why shouldn't backchannel replies have normal timeout values?
>
> RPC Replies are "send and forget". The server forechannel sends
> its Replies without a timeout. There is no such thing as a
> retransmitted RPC Reply (though a reliable transport might
> retransmit portions of it, the RPC server itself is not aware of
> that).
>
> And I don't see anything in the client's backchannel path that
> makes me think there's a different protocol-level requirement
> in the backchannel.

Its not strictly a protocol thing, the timeouts are used to decide what t=
o
do with a req or flag the transport state even if the request doesn't mak=
e
it to the wire.  That's why the zero timeout values for this req improper=
ly
resets the transport.

Ben