* [PATCH] SUNRPC: Check if we need to recalculate slack estimates @ 2025-11-19 13:32 Scott Mayhew 2025-11-19 15:48 ` Chuck Lever 0 siblings, 1 reply; 6+ messages in thread From: Scott Mayhew @ 2025-11-19 13:32 UTC (permalink / raw) To: trondmy, anna; +Cc: linux-nfs 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. + */ + 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)) -- 2.51.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates 2025-11-19 13:32 [PATCH] SUNRPC: Check if we need to recalculate slack estimates Scott Mayhew @ 2025-11-19 15:48 ` Chuck Lever 2026-01-02 12:34 ` Salvatore Bonaccorso 0 siblings, 1 reply; 6+ messages in thread From: Chuck Lever @ 2025-11-19 15:48 UTC (permalink / raw) To: Scott Mayhew, trondmy, anna; +Cc: linux-nfs 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)) -- Chuck Lever ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates 2025-11-19 15:48 ` Chuck Lever @ 2026-01-02 12:34 ` Salvatore Bonaccorso 2026-01-02 14:49 ` Chuck Lever 2026-02-13 22:45 ` Scott Mayhew 0 siblings, 2 replies; 6+ messages in thread From: Salvatore Bonaccorso @ 2026-01-02 12:34 UTC (permalink / raw) To: Chuck Lever; +Cc: Scott Mayhew, trondmy, anna, linux-nfs 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! Regards, Salvatore ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates 2026-01-02 12:34 ` Salvatore Bonaccorso @ 2026-01-02 14:49 ` Chuck Lever 2026-02-13 22:45 ` Scott Mayhew 1 sibling, 0 replies; 6+ messages in thread From: Chuck Lever @ 2026-01-02 14:49 UTC (permalink / raw) To: Salvatore Bonaccorso; +Cc: Scott Mayhew, trondmy, anna, linux-nfs On 1/2/26 7:34 AM, 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? Hello Salvatore - After further consideration, we concluded the above change is not an adequate repair for this issue. The winter holidays have prevented further progress, but I expect Scott will continue looking into a better fix starting next week. -- Chuck Lever ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates 2026-01-02 12:34 ` Salvatore Bonaccorso 2026-01-02 14:49 ` Chuck Lever @ 2026-02-13 22:45 ` Scott Mayhew 2026-02-14 15:57 ` Salvatore Bonaccorso 1 sibling, 1 reply; 6+ messages in thread From: Scott Mayhew @ 2026-02-13 22:45 UTC (permalink / raw) To: Salvatore Bonaccorso; +Cc: Chuck Lever, trondmy, anna, linux-nfs 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 -Scott > > Regards, > Salvatore > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates 2026-02-13 22:45 ` Scott Mayhew @ 2026-02-14 15:57 ` Salvatore Bonaccorso 0 siblings, 0 replies; 6+ messages in thread From: Salvatore Bonaccorso @ 2026-02-14 15:57 UTC (permalink / raw) To: Scott Mayhew; +Cc: Chuck Lever, trondmy, anna, linux-nfs 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-02-14 17:50 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-19 13:32 [PATCH] SUNRPC: Check if we need to recalculate slack estimates Scott Mayhew 2025-11-19 15:48 ` Chuck Lever 2026-01-02 12:34 ` Salvatore Bonaccorso 2026-01-02 14:49 ` Chuck Lever 2026-02-13 22:45 ` Scott Mayhew 2026-02-14 15:57 ` Salvatore Bonaccorso
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox