Re: [PATCH] loop: defer the queue limits clear to a workqueue

[Bart Van Assche]

On 9/24/26 3:20 AM, Tao Cui wrote:
> +	memflags = blk_mq_freeze_queue(lo->lo_queue);
> +	mutex_lock(&lo->clear_limits_lock);
> +	if (lo->clear_limits_gen == lo->rebind_gen) {
> +		mode = lo->clear_limits_mode;
> +		lo->clear_limits_mode = 0;
> +
> +		if (mode & FALLOC_FL_ZERO_RANGE)
> +			lim.max_write_zeroes_sectors = 0;
> +
> +		if (mode & FALLOC_FL_PUNCH_HOLE) {
> +			lim.max_hw_discard_sectors = 0;
> +			lim.discard_granularity = 0;
> +		}
> +	}

I propose to remove the member variables clear_limits_gen and
rebind_gen. These member variables complicate verifying correctness
of the code and IMHO are not necessary. If loop_clear_limits() races
with loop_clear_limits_workfn(), the work will be rescheduled and
loop_clear_limits_workfn() will be called another time.

>   	queue_limits_commit_update(lo->lo_queue, &lim);
> +	mutex_unlock(&lo->clear_limits_lock);

Since the mutex_lock(&lo->clear_limits_lock) call occurs after
queue_limits_start_update(), please move the
mutex_unlock(&lo->clear_limits_lock) call above the
queue_limits_commit_update() call. This has no impact on
correctness nor on the lock nesting order but makes the code
easier to follow.

Thanks,

Bart.