Hi,
在 2025/07/03 9:51, Ming Lei 写道:
On Wed, Jul 02, 2025 at 06:30:34PM -0700, Bart Van Assche wrote:
On 7/2/25 6:15 PM, Yu Kuai wrote:
Just a question, blk_mq_quiesce_queue also calls synchronize_rcu() to
wait for inflight dispatch work to be done, is it safe in following
patches? I think it's not, dispatch work can be running while there is
no request pending, menas queue can be frozen with active dispatch work.
No work is dispatched if a queue is frozen because freezing a queue only
finishes after q_usage_counter drops to zero. queue_rq() and queue_rqs()
are only called if one or more requests are being executed.
q_usage_counter is increased when a request is allocated and decreased
when a request is freed. Hence, q_usage_counter cannot be zero while
queue_rq() or queue_rqs() is in progress. Hence, neither queue_rq() nor
queue_rqs() are called while q_usage_counter is zero.
It isn't related with queue_rq() or queue_rqs() only.
The dispatch work is still in-progress when all requests are
completed(.q_usage_counter becomes zero), because request can complete any
time, even before queue_rq()/queue_rqs() returns.
The dispatch critical area is much _longer_ than queue_rq()/queue_rqs(),
block layer data structure may still be accessed after .q_usage_counter drops
to zero.
Yes, the critical area is protected by rcu/srcu, you can see this in
__blk_mq_run_dispatch_ops.
There can be request pending while blk_mq_hw_queue_need_run() is
checking, and request can complete before __blk_mq_run_dispatch_ops().
Thanks,
Kuai
Please run 'git grep', and we did fix such kind of issues several times, such as:
662156641bc4 ("block: don't drain in-progress dispatch in blk_cleanup_queue()")
Thanks,
Ming
.
