Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Scott,

On Fri, Feb 13, 2026 at 05:45:15PM -0500, Scott Mayhew wrote:
> On Fri, 02 Jan 2026, Salvatore Bonaccorso wrote:
> 
> > Hi Chuck, Scott,
> > 
> > On Wed, Nov 19, 2025 at 10:48:47AM -0500, Chuck Lever wrote:
> > > On 11/19/25 8:32 AM, Scott Mayhew wrote:
> > > > If the incoming GSS verifier is larger than what we previously recorded
> > > > on the gss_auth, that would indicate the GSS cred/context used for that
> > > > RPC is using a different enctype than the one used by the machine
> > > > cred/context, and we should recalculate the slack variables accordingly.
> > > > 
> > > > Link: https://bugs.debian.org/1120598
> > > > Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> > > > ---
> > > >  net/sunrpc/auth_gss/auth_gss.c | 8 ++++++++
> > > >  1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
> > > > index 5c095cb8cb20..6da9ca08370d 100644
> > > > --- a/net/sunrpc/auth_gss/auth_gss.c
> > > > +++ b/net/sunrpc/auth_gss/auth_gss.c
> > > > @@ -1721,6 +1721,14 @@ gss_validate(struct rpc_task *task, struct xdr_stream *xdr)
> > > >  	if (maj_stat)
> > > >  		goto bad_mic;
> > > >  
> > > > +	/*
> > > > +	 * Normally we only recalculate the slack variables once after
> > > > +	 * creating a new gss_auth, but we should also do it if the incoming
> > > > +	 * verifier has a larger size than what was previously recorded.
> > > 
> > > No quibble with the code change, but IMO the comment should work a
> > > little harder to explain why the increase is needed. Something like:
> > > 
> > > 	* When the incoming verifier is larger than expected, the
> > > 	* GSS context is using a different enctype than the one used
> > > 	* initially by the machine credential. Force a slack size update
> > > 	* to maintain good payload alignment.
> > > 
> > > I'm summarizing based on your commit message above...
> > > 
> > > 
> > > > +	 */
> > > > +	if (cred->cr_auth->au_verfsize < (XDR_QUADLEN(len) + 2))
> > > > +		__set_bit(RPCAUTH_AUTH_UPDATE_SLACK, &cred->cr_auth->au_flags);
> > > > +
> > > >  	/* We leave it to unwrap to calculate au_rslack. For now we just
> > > >  	 * calculate the length of the verifier: */
> > > >  	if (test_bit(RPCAUTH_AUTH_UPDATE_SLACK, &cred->cr_auth->au_flags))
> > 
> > I was looking in Debian for the state of this and noticed this was
> > later on never applied/submitted to mainline, is this correct? Did it
> > felt through the cracks or is it considered not to be a problem to
> > further tackle?
> > 
> > Thanks a lot for your work and your help!
> 
> Sorry for the delay.  After having had a chance to take a deeper look,
> I think it would be better to try to address this from the rpc.gssd side
> instead of trying to make the kernel cope with having to bounce around
> between different encryption types.
> 
> Unfortunately I fat-fingered your email address when I sent the patches,
> so here's the link:
> https://lore.kernel.org/linux-nfs/20260213224012.2608126-1-smayhew@redhat.com/T/#t

Thank you for the notice, I will watch the thread there with the new
patches.

Many thanks for all your work!

Regards,
Salvatore