public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
* blk_mq_quiesce_queue in del_gendisk
@ 2022-10-19  7:30 Christoph Hellwig
  2022-10-19  8:20 ` Ming Lei
  0 siblings, 1 reply; 2+ messages in thread
From: Christoph Hellwig @ 2022-10-19  7:30 UTC (permalink / raw)
  To: axboe, ming.lei; +Cc: linux-block

Based on the per-tagset srcu for quiesce discusion I've been wondering
why we need the queue quiesce around elevator_exit and rq_qos_exit in
del_gendisk.  At the point where we call it, we've stopped new fs
I/O submissions, and the queue is frozen.  What does the quiesce still
protect against, and if anything can we come up with a cheaper way to
do that?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: blk_mq_quiesce_queue in del_gendisk
  2022-10-19  7:30 blk_mq_quiesce_queue in del_gendisk Christoph Hellwig
@ 2022-10-19  8:20 ` Ming Lei
  0 siblings, 0 replies; 2+ messages in thread
From: Ming Lei @ 2022-10-19  8:20 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: axboe, linux-block

On Wed, Oct 19, 2022 at 09:30:35AM +0200, Christoph Hellwig wrote:
> Based on the per-tagset srcu for quiesce discusion I've been wondering
> why we need the queue quiesce around elevator_exit and rq_qos_exit in
> del_gendisk.  At the point where we call it, we've stopped new fs
> I/O submissions, and the queue is frozen.  What does the quiesce still
> protect against, and if anything can we come up with a cheaper way to
> do that?

There might be in-progress run queue not finished yet, only rcu can
guarantee that.


Thanks, 
Ming


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-10-19  8:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-19  7:30 blk_mq_quiesce_queue in del_gendisk Christoph Hellwig
2022-10-19  8:20 ` Ming Lei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox