linux-kernel - Re: [PATCH v4] nfsd: allow for up to 32 callback session slots

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <173155439694.1734440.14845420245634385370@noble.neil.brown.name>
Date: Thu, 14 Nov 2024 14:19:56 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Jeff Layton" <jlayton@...nel.org>
Cc: "Chuck Lever" <chuck.lever@...cle.com>, "Dai Ngo" <Dai.Ngo@...cle.com>,
 "Tom Talpey" <tom@...pey.com>, "Olga Kornievskaia" <okorniev@...hat.com>,
 linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] nfsd: allow for up to 32 callback session slots

On Thu, 14 Nov 2024, Jeff Layton wrote:
> On Wed, 2024-11-13 at 12:31 +1100, NeilBrown wrote:
> > 
> > So initialising them all to 1 when the session is created, as you do in
> > init_session(), is clearly correct.  Reinitialising them after
> > target_highest_slot_id has been reduced and then increased is not
> > justified by the above.
> > 
> 
> But, once the client and server have forgotten about those slots after
> shrinking the slot table, aren't they effectively new? IOW, once you've
> shrunk the slot table, the slots are effectively "freed". Growing it
> means that you have to allocate new ones. The fact that this patch just
> keeps them around is an implementation detail.

There is no text in the RFC about shrinking or growing or forgetting.
The only meaning given to numbers like ca_maxreqs is that the client
shouldn't use a larger slot number than the given one.

I think the slot table is conceptually infinite and exists in its
entirety from the moment CREATE_SESSION completes to the moment
DESTROY_SESSION completes (or a lease expires or similar).  The client
can limit how much of that infinitude that it will choose to use, and
the server can limit how much of it it will allow to be used so neither
need to store the full infinity.  But it never changes size.
Implementations can choose how much to store in real memory and can
discard every except (I think) the last sequence number seen on any slot
for which a request was sent (client) or accepted (server).

I agree that this seems less that ideal and it would be good if the
protocol has a mechanism for the client and server to agree to reset
the seqid for some slots.  But I cannot find any such mechanism.

Thanks,
NeilBrown