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 <linux-nfs@vger.kernel.org>
Subject: Linux NFSv4.1 client session seqid sometimes advances by 2
Thread-Topic: Linux NFSv4.1 client session seqid sometimes advances by 2
Thread-Index: AQHXL9rIYn3uMMvy90evx7HGhIWLsA==
Date:   Mon, 12 Apr 2021 20:57:15 +0000
Message-ID: <YQXPR0101MB0968E44CE6FB05F22DE27716DD709@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: a79401fa-f313-4d87-517a-08d8fdf58d49
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2021 20:57:15.1422
 (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: t5QEVBBVOpOCE1zoPpWgPRJnaSzmRE6kybw9DC2hYUWJZCYsT7BS3xz3sIdjH3S5iY/Ylu/ZIrQt24NCN03ytA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3557
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Hi,=0A=
=0A=
During testing of a Fedora Core 30 (5.2.10 kernel) against a FreeBSD=0A=
server (4.1 mount), I have been simulating a network partitioning=0A=
for a few minutes (until the TCP connection goes to SYN_SENT on=0A=
the Linux client).=0A=
=0A=
Sometimes, after the network partition heals, the FreeBSD server=0A=
replies NFS4ERR_SEQ_MISORDERED.=0A=
Looking at the packet trace, the seqid for the slot has advanced by=0A=
2 instead of 1. An RPC request for old-seqid + 1 never seems to get=0A=
sent.=0A=
--> Since sending an RPC with "seqid + 2" but never sending one=0A=
       that is "seqid + 1" for a slot seems harmless, I have added an optio=
nal=0A=
       hack (can be turned off), to allow this case instead of replying=0A=
       NFS4ERR_SEQ_MISORDERED for it. The code will still reply=0A=
       NFS4ERR_SEQ_MISORDERED if an RPC for the slot with=0A=
       "old seqid + 1" in it.=0A=
       --> Yes, doing this hack is a violation of RFC5661, but I've=0A=
             done it anyhow.=0A=
=0A=
If you are interested in a packet capture with this in it:=0A=
fetch https://people.freebsd.org/~rmacklem/linuxtofreenfs.pcap=0A=
- then look at packet #1945 and #2072=0A=
  --> You'll see that slot #1 seqid goes from 4 to 6. There is no=0A=
         slot#1 seqid 5 RPC sent on the wire.=0A=
         (This packet capture was taken on the Linux client using=0A=
          tcpdump.)=0A=
--> Btw, the "RST battle" you'll see in the above trace between=0A=
       #2005 and #2068 that goes on until the FreeBSD=0A=
       krpc/NFS times out the connection after 6min. seems to be a recent=
=0A=
       FreeBSD TCP bug.=0A=
       I have reproduced this seqid advances by 2 on an older system=0A=
       that does not "RST battle" and allows the reconnect right away,=0A=
       once the network partition is healed, so it does seem to be=0A=
       relevant to this bug.=0A=
=0A=
Someday, I will get around to upgrading to a more recent Linux=0A=
kernel and will test to see if I can still reproduce this bug.=0A=
On 5.2.10, it is intermittent and does not occur every time I=0A=
do the network partitioning test.=0A=
=0A=
Mostly just fyi, rick=0A=