On 10/30/22 07:55, Jinlong Chen wrote:
So I think there is a redundant call to blk_freeze_queue_start(), we
just need to call blk_mq_freeze_queue_wait() after calling
blk_queue_start_drain().
I think it is on purpose that blk_queue_start_drain() freezes the
request queue and never unfreezes it. So if you want to change this
behavior it's up to you to motivate why you want to change this behavior
and also why it is safe to make that change. See also commit
d3cfb2a0ac0b ("block: block new I/O just after queue is set as dying").
I think there might be some misunderstanding. I didn't touch
blk_queue_start_drain(), so its behavior is not changed. What I have done
is just replacing blk_freeze_queue() with blk_mq_freeze_queue_wait() in
blk_mq_destroy_queue().
Hi Jinlong,
Does this mean that you want me to provide more information about what I
wrote? Without this patch, blk_mq_destroy_queue() uses two mechanisms to
block future I/O requests:
1. Set the flag QUEUE_FLAG_DYING.
2. Freeze the request queue and leave it frozen.
Your patch modifies blk_mq_destroy_queue() such that it unfreezes the
request queue after I/O has been quiesced instead of leaving it frozen.
I would appreciate it if Ming Lei (Cc-ed) could comment on this change
since I think that Ming introduced (2) in blk_mq_destroy_queue()
(formerly called blk_cleanup_queue()).
Thanks,
Bart.
