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

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.

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

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.

A stable tag is on this commit, so it will get picked up by
stable automation as soon as Linus merges it. That will
include 7.2.y, which will still be open at that point.

Notes:

The Fixes tag refers to a commit in v4.16. That makes it
technically a fix for a bug that was introduced not in the
most recent merge window.

My general policy is to subject fixes to the same review
and CI that is mandated for any other change regardless
of urgency, since historically getting such fixes in
quickly has been the source of defects in released
kernels.

Both CI and review latency are subject to forces outside
of my control so I leave a lengthy window for both.


-- 
Chuck Lever