On Fri, Dec 13, 2024 at 11:12:41AM +0000, David Woodhouse wrote:
> On Fri, 2024-12-13 at 11:42 +0100, Thomas Gleixner wrote:
> >
> > That's the control thread on CPU0. The hotplug thread on CPU1 is stuck
> > here:
> >
> > task:cpuhp/1 state:D stack:0 pid:24 tgid:24 ppid:2 flags:0x00004000
> > Call Trace:
> > <TASK>
> > __schedule+0x51f/0x1a80
> > schedule+0x3a/0x140
> > schedule_timeout+0x90/0x110
> > msleep+0x2b/0x40
> > blk_mq_hctx_notify_offline+0x160/0x3a0
> > cpuhp_invoke_callback+0x2a8/0x6c0
> > cpuhp_thread_fun+0x1ed/0x270
> > smpboot_thread_fn+0xda/0x1d0
> >
> > So something with those blk_mq fixes went sideways.
>
> $ git bisect bad
> 7678abee0867e6b7fb89aa40f6e9f575f755fb37 is the first bad commit
> commit 7678abee0867e6b7fb89aa40f6e9f575f755fb37 (HEAD)
> Author: Ming Lei <ming.lei@xxxxxxxxxx>
> Date: Tue Nov 12 20:58:21 2024 +0800
>
> virtio-blk: don't keep queue frozen during system suspend
The above commit just adds blk_mq_unfreeze_queue() in virtblk_freeze(),
which may wake up pending request allocation.
Seems frozen processes still can be woken up after suspend_freeze_processes()
returns, then new request allocation can't be completed because there
isn't good CPU for this allocation.
Is it expected to see frozen process to be wakeup during suspend?
If yes, the following patch may be helpful:
diff --git a/block/blk-mq.c b/block/blk-mq.c
index aa340b097b6e..0cfc7a927e7e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -557,6 +557,9 @@ static struct request *__blk_mq_alloc_requests(struct blk_mq_alloc_data *data)
if (tag == BLK_MQ_NO_TAG) {
if (data->flags & BLK_MQ_REQ_NOWAIT)
return NULL;
+
+ if (system_state != SYSTEM_RUNNING)
+ return NULL;
/*
* Give up the CPU and sleep for a random short time to
* ensure that thread using a realtime scheduling class
Thanks,
Ming
