Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Rick Macklem <rmacklem@uoguelph.ca>
To:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: weird Linux client behaviour when there are multiple concurrent
 CB_RECALLs
Thread-Topic: weird Linux client behaviour when there are multiple concurrent
 CB_RECALLs
Thread-Index: AQHXOXfnjixeaFEWH0C9YjMT3U0+MQ==
Date:   Sun, 25 Apr 2021 02:29:14 +0000
Message-ID: <YQXPR0101MB0968124A7F9024769EC90F23DD439@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e7bbf777-2580-4d52-6277-08d90791eae3
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2021 02:29:14.1409
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OPbU6W582MFaajyzgHUogfTYAQY+vdoLZ+xx8fqbGAbJfBOiemDwpAHOZ4YwwKAbqt+47YAKZ5Bk+Gw85rAbbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2867
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Hi,=0A=
=0A=
I have been running a simple test using two clients (one FreeBSD=0A=
and the other Linux, Ferdora Core30, 5.2 kernel) with delegations=0A=
enabled in the server.=0A=
=0A=
The test consists of running the connectathon general tests=0A=
alternately om each client, using the same directory on the=0A=
server.=0A=
--> As such, each one results in CB_RECALLs of delegations=0A=
      from the other client.=0A=
Everything seems fine until the server does multiple concurrent=0A=
CB_RECALLs for different files/delegations using different=0A=
callback session slots.=0A=
--> Then the Linux client decides it must create a new connection,=0A=
       which breaks the back channel.=0A=
       After 0.1sec, the FreeBSD server notices the broken back=0A=
       channel and starts setting SEQ4_STATUS_CB_PATH_DOWN.=0A=
       --> 15sec after that, the Linux client does a BindConnectionToSessio=
n=0A=
              and things start working again.=0A=
=0A=
The mystery to me is why the client decides to create a new TCP=0A=
connection, forcing this 15sec hickup each time it happens?=0A=
=0A=
If you are interested in looking at a packet capture. you can=0A=
% fetch https://people.freebsd.org/~rmacklem/twoclientdeleg.pcap=0A=
There are multiple examples in it. One is at:=0A=
packet# 3518, 3520, 3521 CB_RECALL requests for 3 different delegations=0A=
                         time 137.5=0A=
--> This is followed by a close and open of a new TCP connection...=0A=
packet# 3582 - first one with SEQ4_STATUS_CB_PATH_DOWN at=0A=
                         time 137.6=0A=
packet# 3604 - client does a bindconnectiontosession at=0A=
                         time 152.7=0A=
Then things start to happen again...=0A=
192.168.1.5 - FreeBSD server=0A=
192.168.1.6 - Linux client=0A=
192.168.1.13 - FreeBSD client=0A=
=0A=
If this is a known issue that you think is fixed in a more recent=0A=
Linux kernel, then sorry about the noise.=0A=
=0A=
rick=0A=