linux-ext4 - Re: Lockdep warnings on kexec (virtio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z1wbiF7FhkO5VQFJ@fedora>
Date: Fri, 13 Dec 2024 19:33:28 +0800
From: Ming Lei <ming.lei@...hat.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Stefan Hajnoczi <stefanha@...hat.com>,
	Jason Wang <jasowang@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	hpa <hpa@...or.com>, dyoung <dyoung@...hat.com>,
	kexec <kexec@...ts.infradead.org>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Stefano Garzarella <sgarzare@...hat.com>,
	eperezma <eperezma@...hat.com>, Paolo Bonzini <bonzini@...hat.com>,
	Petr Mladek <pmladek@...e.com>, John Ogness <jogness@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>, Jens Axboe <axboe@...nel.dk>
Subject: Re: Lockdep warnings on kexec (virtio_blk, hrtimers)

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@...hat.com>
> 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