linux-kernel - Re: WARNING: CPU: 3 PID: 1 at block/blk-mq-cpumap.c:90 blk_mq_map_hw

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: <0ec86878-d3c4-400c-a312-9452bf229d45@flourine.local>
Date: Wed, 22 Jan 2025 18:08:35 +0100
From: Daniel Wagner <dwagner@...e.de>
To: Christoph Hellwig <hch@....de>
Cc: LKML <linux-kernel@...r.kernel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Daniel Wagner <wagi@...nel.org>, Hannes Reinecke <hare@...e.de>, 
	Ming Lei <ming.lei@...hat.com>, John Garry <john.g.garry@...cle.com>, 
	Jens Axboe <axboe@...nel.dk>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: WARNING: CPU: 3 PID: 1 at block/blk-mq-cpumap.c:90
 blk_mq_map_hw_queues+0xf3/0x100

On Wed, Jan 22, 2025 at 09:30:20AM -0500, Steven Rostedt wrote:
> I hit this WARN_ON on both my 32 bit test VM and my 64 bit one:
> 
> [    1.861456] ------------[ cut here ]------------
> [    1.862394] WARNING: CPU: 3 PID: 1 at block/blk-mq-cpumap.c:90 blk_mq_map_hw_queues+0xf3/0x100
> [    1.864100] Modules linked in:
> [    1.864785] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.0-test-01253-g66611c047570-dirty #128
> [    1.866545] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [    1.868320] EIP: blk_mq_map_hw_queues+0xf3/0x100

[...]

> Seems introduced by: 1452e9b470c90 ("blk-mq: introduce blk_mq_map_hw_queues")
> 
> Config for x86_64 attached.

Thanks I was able to reproduce it and was able to figure out that
vp_get_vq_affinity returns a NULL CPU mask which makes
blk_mq_map_hw_queues call the fallback code path with the WARN_ON_ONCE
from above.

The blk_mq_virtio_map_queues used blk_mq_map_queues for creating a map:

blk_mq_virtio_map_queues(...)
{
        [...]

        for (;;) {
                mask = vdev->config->get_vq_affinity(...);
                if (!mask)
                        goto fallback;

                [...]
        }

        return;

fallback:
       blk_mq_map_queues(...);
}


blk_mq_map_hw_queues(...)
{

	for (;;) {
		mask = dev->bus->irq_get_affinity(...);
		if (!mask)
			goto fallback;

                [...]
	}

        return

fallback:
	WARN_ON_ONCE(qmap->nr_queues > 1);
	blk_mq_clear_mq_map(...)
}

I was where blk_mq_clear_mq_map is coming from. The origin is from
blk_mq_pci_map_queues

c00539037495 ("blk-mq-pci: add a fallback when pci_irq_get_affinity
returns NULL")

    blk-mq-pci: add a fallback when pci_irq_get_affinity returns NULL

    While pci_irq_get_affinity should never fail for SMP kernel that
    implement the affinity mapping, it will always return NULL in the
    UP case, so provide a fallback mapping of all queues to CPU 0 in
    that case.

What about using blk_mq_mp_queues instead of blk_mq_clear_mq_map, it
should give the same mapping as with blk_mq_clear_mq_map. And obviously
removing the WARN_ON_ONCE. Basically use the version from
blk_mq_virtio_map_queues for the fallback code path.

Christoph, would this be acceptable?

Daniel