Message-id: <176281669984.634289.12369219545843965992@noble.neil.brown.name>
Date: Tue, 11 Nov 2025 10:18:19 +1100
From: NeilBrown <neilb@...mail.net>
To: "Chuck Lever" <chuck.lever@...cle.com>
Cc: stable@...r.kernel.org, "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()

On Mon, 10 Nov 2025, Chuck Lever wrote:
> 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.

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@...wn.name>
> 
> -- 
> Chuck Lever
> 

Powered by blists - more mailing lists