linux-kernel - Re: [PATCH stable 6.1.y] nfsd: use __clamp in nfsd4_get_drc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <17e85980-9af9-4320-88d1-fa0c9a7220b1@oracle.com>
Date: Sun, 9 Nov 2025 20:00:54 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: NeilBrown <neil@...wn.name>, stable@...r.kernel.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        David Laight <David.Laight@...LAB.COM>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        speedcracker@...mail.com
Subject: Re: [PATCH stable 6.1.y] nfsd: use __clamp in nfsd4_get_drc_mem()

Hi Neil -

On 11/9/25 4:45 PM, NeilBrown wrote:
> 
> From: NeilBrown <neil@...wn.name>
> 
> A recent change to clamp_t() in 6.1.y caused fs/nfsd/nfs4state.c to fail
> to compile with gcc-9.

I have a comment on merge process:

Reported on 6.1.y, but might be present in other LTS releases, since
2030ca560c5f exists in every LTS kernel since v5.4.y.

At least, my understanding of the stable rules is that they prefer this
kind of patch be applied to all relevant LTS kernels. I strongly prefer
that NFSD experts review and test this change /before/ it is merged,
since nfsd4_get_drc_mem() is part of the NFSv4.1 session slot
implementation, and since in this case we don't get the benefit of
/any/ soak time in linux-next or an upstream -rc release.

So IMHO this patch needs to target v6.12.y, not v6.1.y, and it should be
marked

Fixes: 2030ca560c5f ("nfsd: degraded slot-count more gracefully as
allocation nears exhaustion.")

(Since the patched code hasn't changed in many years, I think the final
patch ought to apply cleanly to both 6.12.y and 6.1.y).

I need to take the fix into nfsd-6.12.y and run NFSD CI against it, then
it can be sent along to stable@, and they will put it back into the
older LTS kernels for us.


> The code was written with the assumption that when "max < min",
>    clamp(val, min, max)
> would return max.  This assumption is not documented as an API promise
> and the change cause a compile failure if it could be statically
> determined that "max < min".
> 
> The relevant code was no longer present upstream when the clamp() change
> landed there, so there is no upstream change to backport.
> 
> As there is no clear case that the code is functioning incorrectly, the
> patch aims to restore the behaviour to exactly that before the clamp
> change, and to match what compilers other than gcc-9 produce.

> clamp_t(type,v,min,max) is replaced with
>   __clamp((type)v, (type)min, (type)max)
> 
> Some of those type casts are unnecessary but they are included to make
> the code obviously correct.
> (__clamp() is the same as clamp(), but without the static API usage
> test).
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c0
> Fixes: 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()")

Stable-dep-of: 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the
lo < hi test in clamp()")

might be more appropriate.


> Signed-off-by: NeilBrown <neil@...wn.name>

-- 
Chuck Lever