Re: [PATCH v4 1/1] NFSD: Enforce Timeout on Layout Recall and Integrate Lease Manager Fencing

[Dai Ngo <dai.ngo@oracle.com>]

On 1/27/26 10:14 AM, Jeff Layton wrote:
> On Tue, 2026-01-27 at 12:11 -0500, Chuck Lever wrote:
>>> +
>>> +	if (work_busy(&ls->ls_fence_work.work))
>>> +		return false;
>>> +	/* Schedule work to do the fence operation */
>>> +	ret = mod_delayed_work(system_dfl_wq, &ls->ls_fence_work, 0);
>>> +	if (!ret) {
>>> +		/*
>>> +		 * If there is no pending work, mod_delayed_work queues
>>> +		 * new task. While fencing is in progress, a reference
>>> +		 * count is added to the layout stateid to ensure its
>>> +		 * validity. This reference count is released once fencing
>>> +		 * has been completed.
>>> +		 */
>>> +		refcount_inc(&ls->ls_stid.sc_count);
>>> +		++ls->ls_fence_retry_cnt;
>>> +		return true;
>>> +	}
>> Incrementing after the mod_delayed_work() call is racy. Instead:
>>
>> refcount_inc(&ls->ls_stid.sc_count);
>> ret = mod_delayed_work(system_dfl_wq, &ls->ls_fence_work, 0);
>> if (ret) {
>>      refcount_dec(&ls->ls_stid.sc_count);
>>      ....
>> }
>>
> Is that safe? That's done in nfsd_break_one_deleg() for similar
> reasons, but there is a comment over that function explaining why it's
> OK.
>
> We'll need to validate that the lease is always released before the
> sc_count goes to 0 here too. At first glance, it doesn't look like that
> is the case.

No, it's not safe. I have to think of other ways to make sure the
layout statid is valid when the fence worker runs.

-Dai

>
>