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

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.

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