From: Tao Cui <cui.tao@linux.dev>
To: Bart Van Assche <bvanassche@acm.org>, axboe@kernel.dk, hch@lst.de
Cc: cui.tao@linux.dev, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, Tao Cui <cuitao@kylinos.cn>
Subject: Re: [PATCH] loop: defer the queue limits clear to a workqueue
Date: Tue, 1 Sep 2026 21:14:14 +0800 [thread overview]
Message-ID: <583d8fd2-3f10-4714-8cdb-5b9d27f3cf11@linux.dev> (raw)
In-Reply-To: <b6af880e-66df-484d-b776-8ca72aac3b1a@acm.org>
Hi Bart,
在 2026/9/1 00:25, Bart Van Assche 写道:
> On 8/28/26 12:20 AM, Tao Cui wrote:
>> The code already has an XXX comment saying this should move to a
>> workqueue. Do that: schedule a work item on the system workqueue,
>> where it is safe to freeze the queue and update the limits using
>> queue_limits_commit_update_frozen().
> The patch description explains why queue freezing is necessary but
> does not add queue freeze and unfreeze calls. Is that perhaps an
> oversight?
>
Good question, I should have spelled this out in the commit
message. The freeze and unfreeze are inside
queue_limits_commit_update_frozen() itself (block/blk-settings.c):
memflags = blk_mq_freeze_queue(q);
ret = queue_limits_commit_update(q, lim);
blk_mq_unfreeze_queue(q, memflags);
The naming is a bit counterintuitive: the _frozen variant is the
one that freezes the queue itself, while the plain
queue_limits_commit_update() expects the caller to have frozen the
queue already ("The caller must have frozen the queue or ensure
that there are no outstanding I/Os by other means"). The in-tree
callers use it that way too - blk_integrity_unregister() and the
sd.c revalidation paths call the _frozen variant without freezing
the queue themselves.
The old loop_clear_limits() was exactly a caller that did not meet
that expectation, since it ran in the loop workqueue where the
queue cannot be frozen, so moving to the work item and using the
_frozen wrapper is the fix.
Thanks,
Tao
> Thanks,
>
> Bart.
next prev parent reply other threads:[~2026-09-01 13:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 7:20 [PATCH] loop: defer the queue limits clear to a workqueue Tao Cui
2026-08-28 16:34 ` Bart Van Assche
2026-08-31 13:34 ` Tao Cui
2026-08-31 16:25 ` Bart Van Assche
2026-09-01 13:14 ` Tao Cui [this message]
2026-09-01 17:29 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=583d8fd2-3f10-4714-8cdb-5b9d27f3cf11@linux.dev \
--to=cui.tao@linux.dev \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=cuitao@kylinos.cn \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.