On Mon, 10 Nov 2025, Chuck Lever wrote:
Hi Neil -
On 11/9/25 4:45 PM, NeilBrown wrote:
From: NeilBrown neil@brown.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.
I thought this might be likely but I didn't have enough motivation to check.
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.
The patch is deliberately written to transparent without requiring any (export or otherwise) understand of the NFS or even of the code being changed. It purely removes the BUILD_BUG_ON().
So IMHO this patch needs to target v6.12.y, not v6.1.y, and it should be marked
Can I leave the process management to you. Though as you say later, the same patch should apply equally to both.
Fixes: 2030ca560c5f ("nfsd: degraded slot-count more gracefully as allocation nears exhaustion.")
There is no evidence that patch is broken so it is hard to justify saying that we fixed it. But I honestly don't care.
(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()")
I haven't come across Stable-dep-of before. I can't find it in Documentation. Looking at some examples I guess it makes sense. Except that Stable-dep-of normally comes before, and Fixes normally comes after the target...
Thanks, NeilBrown
might be more appropriate.
Signed-off-by: NeilBrown neil@brown.name
-- Chuck Lever