Received-SPF: pass (google.com: domain of linux-nfs+bounces-1129-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: Connor Smith <connor.smith@hitachivantara.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Possible discrepancy in CREATE_SESSION slot number accounting
Thread-Topic: Possible discrepancy in CREATE_SESSION slot number accounting
Thread-Index: AdpIgOxAPAgULydbT7evjuyQgxyM6g==
Date: Tue, 16 Jan 2024 13:52:12 +0000
Message-ID:
 <DM8PR08MB72883F3D2AF2A0638CD41356E8732@DM8PR08MB7288.namprd08.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?OJSbC4qIjttTAlmdFlBWaIGn8GXvrirknMvepmpOjZ+iblwjKqxrXPYVj/69?=
 =?us-ascii?Q?nTCr/2y7fb1XwULsaqw2iZIPoCLm5gmxTiehykpcAN1a45RGZNNvLyct3Mpn?=
 =?us-ascii?Q?/xi6+kCFdMl4LNnXVsIWDDHmbNd7HOL7yIGS5oAsmH/QU6dZanfoKL4qNHph?=
 =?us-ascii?Q?31xL8C652j4qIzPnoadKafSl7KFmY9iy9TlmpeRM5bQAmpuHJVxi1K7n/S5K?=
 =?us-ascii?Q?PEORrkrRpE54iEeD2mcNxtCjsEvIkhyOQiJJ4NuBtOKKGMhh5jh3wAxYxl0g?=
 =?us-ascii?Q?3pz/HbE1DUJ+ixFHrfPoZDZxYmy5dKmXYijKEfZAygUqKYJo+SSBCgwX0k4r?=
 =?us-ascii?Q?hAA4iRODkq8KcVUgmIeXmv2R+nPUky1eJIOiFO9JmV0eCUntLOxLfZvINbrI?=
 =?us-ascii?Q?PJXoWOVWapuwyd3XLiPPN9k8ApP6q9nVl+NPyNdhixt9COWtv3IOrvoxDvm7?=
 =?us-ascii?Q?7pwszs/bvZ1yC7ojSKXVfknDbM6q3SsMow3QZQmflOm4dGLlJ6J1UkLXI5DY?=
 =?us-ascii?Q?nb/4O1ASm8ImMjSse7mQxhZPWFYOypb+nK13qU6hiWLxA8KK0xGrXvzPgo+F?=
 =?us-ascii?Q?TiIOLw1rdo2DCcxLd+EIIPyzzJvXFkG/YFts6AYiwknANgmFFNK02kdGiQxd?=
 =?us-ascii?Q?6uU+ip9LgOzX6EBsT+rB5kFcwijqFqg+Gz/B20AIOPYXtuq8yIoVIGP38uN5?=
 =?us-ascii?Q?j5fue/me0Y/M/eu9zwBAi4MfNTKN4I0gLpP4uWA3giphonq6yNLhN7lGRliu?=
 =?us-ascii?Q?BpRWTeTYG++tY99/bjiQ2MUG8tNsmbICzueFayYFQnW4V4XJsHmlR2Lx/e8D?=
 =?us-ascii?Q?i9eAbllbfCBAuyRSzjD+/wjkoyqf1nE9/n5ghd8OEG6JVC8JG3oox/aQV150?=
 =?us-ascii?Q?mEAR2LchTFsh5n91d2RpB5peoh2oOP2XmpYwCgkeCZD/2sqp7tb2Z+5n45+r?=
 =?us-ascii?Q?vsn9FA3Ogyfw/90oJUDHjtPDriM6s5Xqcd7K5AZo33pZSaFSN7+lB01ExL7m?=
 =?us-ascii?Q?Q9sCWbRownu6LK2Xojs0bQsUifwMHCMaGHexqvfSekgOIB30zwJCO0exi9UC?=
 =?us-ascii?Q?lfCnS6eiszQFkrh7WNC+zlbZDAAbT694pBvgE9RsrMlfjZ5mMKB3AlahDSg/?=
 =?us-ascii?Q?Z0gPwDMBfM0cDUDe5V193UmaRMhl2TdBXZtPIyQIpidcI4ibHjFc0HAFgj4j?=
 =?us-ascii?Q?TWmf9s63YCm6A2jkFPQlxfwv7JD6nqVzvDyYD9Ctx5/krUHZGk+2jat3U5EE?=
 =?us-ascii?Q?RFIA7pNePyLKOxkqCEpp4VqGtNthdsljDLNGDN1IygEKSWqCRSSzdKnhNHl4?=
 =?us-ascii?Q?XUdD5j0NZCvVGyskh2HYiyPSp58xAuwCG9P+/WPy4I2oj9YNOgpsejhb1A+K?=
 =?us-ascii?Q?qR3ZotcQOnIK+odLVHhahGZFxtOwhNPsSELmuyD3dNlJpAXjmHV+PxKqM2WM?=
 =?us-ascii?Q?HGP89pOslep96EPV29bqzcDekWbDh0b1UcMIBl2N7t35bDde6h3jLQh+icqB?=
 =?us-ascii?Q?GBOreV7E1irQaV05vOaZp0mRAJByl14A7QYC+YBms5LF1qG29bl0DzlDXp4k?=
 =?us-ascii?Q?CRVGxxCULacH0bk08L2G4MSZaU/F8lccCS4dSL7PUOo47UZMedQDHGSNgOcx?=
 =?us-ascii?Q?MA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-nfs@vger.kernel.org
List-Id: <linux-nfs.vger.kernel.org>
List-Subscribe: <mailto:linux-nfs+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-nfs+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: hitachivantara.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM8PR08MB7288.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 785f20e6-e8b5-48c2-423a-08dc169a5720
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2024 13:52:12.1891
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 18791e17-6159-4f52-a8d4-de814ca8284a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2M2vEnyfFF3nevVU58C+YQIVP2BsjLAvbfKDCplSpvNfB4axoA7Y0zuuCcNy4o9oihTH18U0YuLG5UfuOnXbqzNnLpALxcGMKI0gNSuOACY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0801MB7760

Hi,

I noticed what I think might be a discrepancy in the way Linux nfs and nfsd=
 manage CREATE_SESSION reply cache sequence IDs.

In fs/nfs/nfs4proc.c (_nfs4_proc_create_session), the seqid looks to be inc=
remented so long as the status is not one of NFS4ERR_STALE_CLIENTID, NFS4ER=
R_DELAY, or an RPC timeout. This is mostly due to:

commit b519d408ea32040b1c7e10b155a3ee9a36660947
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sun Sep 11 14:50:01 2016 -0400

    NFSv4.1: Fix the CREATE_SESSION slot number accounting

    Ensure that we conform to the algorithm described in RFC5661, section
    18.36.4 for when to bump the sequence id. In essence we do it for all
    cases except when the RPC call timed out, or in case of the server retu=
rning
    NFS4ERR_DELAY or NFS4ERR_STALE_CLIENTID.

(Note that the comment /* Increment the clientid slot sequence id */ not be=
ing moved in the above commit has, I think, left it in the wrong place.)

Meanwhile, in fs/nfsd/nfs4state.c (nfsd4_create_session), the seqid looks t=
o be incremented only when the session has been successfully created and th=
e status will be NFS4_OK. This is mostly due to:=20

commit 86c3e16cc7aace4d1143952813b6cc2a80c51295
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Sat Oct 2 17:04:00 2010 -0400

    nfsd4: confirm only on succesful create_session

    Following rfc 5661, section 18.36.4: "If the session is not successfull=
y
    created, then no changes are made to any client records on the server."
    We shouldn't be confirming or incrementing the sequence id in this case=
.

My reading of RFC8881 18.36.4 suggests that the former is correct - after t=
he sequence ID has been processed in phase 2...

> [...] the CREATE_SESSION processing goes to the next phase. A subsequent =
new CREATE_SESSION call over the same client ID MUST use a csa_sequenceid t=
hat is one greater than the sequence ID in the slot.

Client ID confirmation is in phase 3, for example, and returns NFS4ERR_CLID=
_INUSE. Since this is after phase 2, the sequence ID should be incremented =
on that error code. My understanding is that a "client record" refers speci=
fically to the 5-tuple described in 18.35.4, which does not include the CRE=
ATE_SESSION reply cache, so although I think the latter commit was right to=
 move the confirmation of the client record, I'm not sure about the increme=
nting of the sequence ID.

Apologies if I'm mistaken about something here, but I was confused by what =
looked to me like a difference in 'slot number accounting'.

Thanks,
Connor