[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46a5ec83-5a26-fc8a-4cd9-a77d100b7833@acm.org>
Date: Sun, 9 Feb 2020 19:14:48 -0800
From: Bart Van Assche <bvanassche@....org>
To: "yukuai (C)" <yukuai3@...wei.com>, axboe@...nel.dk,
ming.lei@...hat.com, chaitanya.kulkarni@....com,
damien.lemoal@....com, dhowells@...hat.com, asml.silence@...il.com,
ajay.joshi@....com
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
yi.zhang@...wei.com, zhangxiaoxu5@...wei.com,
luoshijie1@...wei.com, jan kara <jack@...e.cz>
Subject: Re: [PATCH] block: revert pushing the final release of request_queue
to a workqueue.
On 2020-02-09 18:13, yukuai (C) wrote:
> I tested following patch fixes the problem, however I'm not sure if
> move blk_trace_shutdown() and blk_mu_exit_queue() is ok or we should
> just move debgfs-related part.
>From blk-mq.c:
/* tags can _not_ be used after returning from blk_mq_exit_queue */
void blk_mq_exit_queue(struct request_queue *q)
{
struct blk_mq_tag_set *set = q->tag_set;
blk_mq_del_queue_tag_set(q);
blk_mq_exit_hw_queues(q, set, set->nr_hw_queues);
}
I think that calling blk_mq_exit_queue() from blk_unregister_queue()
would break at least the sd driver. The sd driver can issue I/O after
having called del_gendisk(). See also the sd_sync_cache() call in
sd_shutdown().
Bart.
Powered by blists - more mailing lists