Re: [PATCH v4 1/9] NFSD: Prevent lock owner use-after-free during client teardown

Hello Thorsten!

Am 2026-07-22 16:33, schrieb Thorsten Leemhuis:
> On 7/22/26 15:48, Chuck Lever wrote:
>> On Wed, Jul 22, 2026, at 6:24 AM, Thorsten Leemhuis wrote:
>>> On 7/9/26 19:40, Chuck Lever wrote:
>>>> __destroy_client() releases a client's open owners, but a lock owner
>>>> whose only reference is a blocked lock (nbl) stays on
>>>> cl_ownerstr_hashtbl.  client_has_state() does not count a bare 
>>>> owner,
>>>> so DESTROY_CLIENTID can reach __destroy_client() with such owners
>>>> present.
>>>> 
>>>> [...]
>>>> 
>>>> Reported-by: Wolfgang Walter <[email protected]>
>>>> Closes: 
>>>> https://lore.kernel.org/linux-nfs/[email protected]/
>>>> Fixes: 68ef3bc31664 ("nfsd: remove blocked locks on client 
>>>> teardown")
>>> 
>>> What's the plan to merge this change? From the outside it looks like 
>>> a
>>> fix for a user reported regression from this merge window, as 
>>> Wolfgang
>>> afaics blamed commit 516403d4d85607 ("Revert "NFSD: Defer sub-object
>>> cleanup in export put callbacks""), which also made it to various 
>>> stable
>>> trees.
>>> 
>>> So shouldn't this change ideally be on it's way to Linus by now? 
>>> Ideally
>>> with a stable tag to ensure quick backporting? Or is it not a good 
>>> idea
>>> to have this in without the follow-up patches from this series?
>>> 
>>> Or did I get something totally wrong (which is easily possible from 
>>> my
>>> external point)?
>> 
>> Thorsten, thanks for your attention to this issue.
> 
> Thank you for the answer!
>> Here is the plan of record:
>> 
>> This commit is currently in nfsd-testing:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git/commit/?h=nfsd-testing&id=3055ac7c996369876342aa22a33bcc68cd4abca1
> 
> Ahh, I see, the change gained a stable tag somewhere along the way, 
> great!
> 
>> It will matriculate to nfsd-next in a week or so and then be
>> sent to Linus in the initial nfsd-7.3 pull request.
> 
> Hmmm. Just reread your reply to Wolfgang's report where you explain
> things in more detail:
> https://lore.kernel.org/stable/[email protected]/
> 
> I now understand this better and it still feels to me like a situation
> where Linus would want the fix to be included in mainline quickly[1] --
> among others to not have another release with the bug[2] and because
> it's something a user reported[3]. Yes, the root of the problem might 
> be
> in an older commit the Fixes: tag quoted above refers to -- but
> apparently something (maybe the change Wolfgang and you suspected) 
> seems
> to have exposed the problem or made it happen more often at least in
> 6.18.y.
> 
> Anyway, if Wolfgang is the only one that seems to hit this and is happy
> with the state of things I guess it's not worth arguing further about.
> 

I'm very happy having this patch and especially that I got it so fast. 
If I build a new version of a stable kernel I just rebase this patch on 
top of it. Git makes carrying such patches very easy.

So I'm pefectly fine if this goes into stable/lts a bit later.

> Thanks again for taking the time to answer my mail!
> 
> Ciao, Thorsten
> 
> [1] and Greg likely as well, as situations like that are the reason why
> stable kernels released during or shortly after the merge window have
> many hundreds of changes that have seen little testing (and we are
> currently at the point where it could get some testing before hitting a
> new release)
> 
> [2]
> https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/
> 
> [3]
> https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

Ciao,
-- 
Wolfgang Walter
Studierendenwerk München Oberbayern
Anstalt des öffentlichen Rechts