On Mon, Feb 06, 2023 at 09:54:47AM -0800, Luis Chamberlain wrote:
> > block/blk-mq.c:4083 blk_mq_destroy_queue() warn: sleeping in atomic context
>
> Let's see as an example.
>
> blk_mq_exit_hctx() can spin_lock() and so could disable preemption but I
> can't see why this is sleeping in atomic context.
>
I should have said, the lines are from linux-next.
block/blk-mq.c
4078 void blk_mq_destroy_queue(struct request_queue *q)
4079 {
4080 WARN_ON_ONCE(!queue_is_mq(q));
4081 WARN_ON_ONCE(blk_queue_registered(q));
4082
4083 might_sleep();
^^^^^^^^^^^^^^
This is a weird example because today's cross function DB doesn't say
which function disables preemption. The output from `smdb.py preempt
blk_mq_destroy_queue` says:
nvme_remove_admin_tag_set()
nvme_remove_io_tag_set()
-> blk_mq_destroy_queue()
I would have assumed that nothing is disabling preempt and the
information just hasn't propagated through the call tree yet. However
yesterday's DB has enough information to show why the warning is
generated.
nvme_fc_match_disconn_ls() takes spin_lock_irqsave(&rport->lock, flags);
-> nvme_fc_ctrl_put(ctrl);
-> kref_put(&ctrl->ref, nvme_fc_ctrl_free);
-> nvme_remove_admin_tag_set(&ctrl->ctrl);
-> blk_mq_destroy_queue(ctrl->admin_q);
-> blk_mq_destroy_queue() <-- sleeps
It's the link between kref_put() and nvme_fc_ctrl_free() where the data
gets lost in today's DB. kref_put() is tricky to handle. I'm just
puzzled why it worked yesterday.
regards,
dan carpenter
