linux-kernel - Re: [PATCH] nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup

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] [day] [month] [year] [list]

Message-ID: <1F8D33B0-6844-4DD6-A673-7EA1F63EDF82@redhat.com>
Date: Thu, 17 Apr 2025 08:48:46 -0400
From: Benjamin Coddington <bcodding@...hat.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Chuck Lever <chuck.lever@...cle.com>, Neil Brown <neilb@...e.de>,
 Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>,
 Tom Talpey <tom@...pey.com>, linux-nfs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nfsd: allow SC_STATUS_FREEABLE when searching via
 nfs4_lookup_stateid()

On 12 Feb 2025, at 11:29, Jeff Layton wrote:

> When a delegation is revoked, it's initially marked with
> SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked
> with the SC_STATUS_FREEABLE flag, which denotes that it is waiting for
> s FREE_STATEID call.
>
> nfs4_lookup_stateid() accepts a statusmask that includes the status
> flags that a found stateid is allowed to have. Currently, that mask
> never includes SC_STATUS_FREEABLE, which means that revoked delegations
> are (almost) never found.
>
> Add SC_STATUS_FREEABLE to the always-allowed status flags.
>
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
> This fixes the pynfs DELEG8 test.

I want to follow-up this patch with the report that this will fix quite
severe TEST_STATEID/FREE_STATEID storms from NFS clients that can never
satisfy the server's setting SEQ4_STATUS_*_STATE_REVOKED status bits.

Correct accounting on the server's cl_revoked counter is pretty important, I
do wish the protocol had something like a per-client global window of valid
state.

Thanks Jeff (and thanks Olga for the original fix!),

Ben