public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Cc: Alexandre Ghiti <alexghiti@rivosinc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Anup Patel <anup@brainfault.org>,
	Sunil V L <sunilvl@ventanamicro.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Bjorn Helgaas <helgaas@kernel.org>,
	1127635@bugs.debian.org,
	"Aaron D. Johnson" <debbugreporter@fnord.greeley.co.us>,
	regressions@lists.linux.dev
Subject: Re: [Patch] PCI/MSI: Handle lack of irqdomain gracefully
Date: Wed, 22 Apr 2026 23:22:11 +0200	[thread overview]
Message-ID: <87qzo61yik.ffs@tglx> (raw)
In-Reply-To: <abE_QoS5DM-ZltaV@monoceros>

On Wed, Mar 11 2026 at 12:22, Uwe Kleine-König wrote:

> this patch became a60b990798eb17433d0283788280422b1bd94b18 in v6.13-rc5
> and was backported to 6.12.y and 6.6.y (aed157301c65 and b1f7476e07b9
> respectively).
>
> A Debian user (Aaron, on Cc:) on powerpc has boot problems and bisected
> them to this commit. The relevant boot log of the failure is:

> [    2.643879] BUG: Kernel NULL pointer dereference on read at 0x00000000
> [    2.643891] Faulting instruction address: 0xc000000000a39514
> [    2.643902] Oops: Kernel access of bad area, sig: 11 [#1]
> [    2.643909] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> [    2.643920] Modules linked in: ohci_pci(+) ehci_hcd nvme_fabrics ohci_hcd nvme_keyring nvme_core usbcore nvme_auth scsi_transport_fc ipr configfs ehea(+) usb_common
> [    2.643965] CPU: 5 UID: 0 PID: 250 Comm: (udev-worker) Not tainted 6.12.17-powerpc64 #1  Debian 6.12.17-1
> [    2.643976] Hardware name: IBM,8204-E8A POWER6 (architected) 0x3e0302 0xf000002 of:IBM,EL350_118 hv:phyp pSeries
> [    2.643986] NIP:  c000000000a39514 LR: c000000000a36ed8 CTR: c000000000a35820
> [    2.643995] REGS: c0000000351f6f60 TRAP: 0300   Not tainted  (6.12.17-powerpc64 Debian 6.12.17-1)
> [    2.644004] MSR:  8000000000009032 <SF,EE,ME,IR,DR,RI>  CR: 24222288  XER: 00000000
> [    2.644031] CFAR: c00000000000cfc4 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
> [    2.644031] GPR00: c000000000a36ed8 c0000000351f7200 c00000000182e200 c0000003df294000
> [    2.644031] GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [    2.644031] GPR08: 0000000000000001 0000000000000000 c00000000228fcc0 0000000044222288
> [    2.644031] GPR12: c000000000a35820 c00000000eeacb00 0000000000000020 0000010037fcab20
> [    2.644031] GPR16: 0000000022222248 0000000000020000 0000000000000000 00003fffebe8bb80
> [    2.644031] GPR20: 0000000000000000 c00000000204db60 c00000000204dd60 c00000000b1ae780
> [    2.644031] GPR24: 0000000000000000 00003fff8c9ac758 0000000000000000 c0000003df294000
> [    2.644031] GPR28: 0000000000000001 0000000000000000 c0000003df294000 0000000000000001
> [    2.644164] NIP [c000000000a39514] pci_msi_domain_supports (drivers/pci/msi/irqdomain.c:366)
> [    2.644181] LR [c000000000a36ed8] __pci_enable_msi_range (drivers/pci/msi/msi.c:437)
> [    2.644192] Call Trace:
> [    2.644197] [c0000000351f7200] [c0000000351f7304] 0xc0000000351f7304 (unreliable)
> [    2.644211] [c0000000351f7340] [c000000000a3578c] pci_alloc_irq_vectors_affinity (drivers/pci/msi/api.c:277)

> ========
>    0:*	41 82 00 2c 	beq     0x2c		<-- trapping instruction
>    4:	e9 2a 00 88 	ld      r9,136(r10)
>    8:	80 69 00 00 	lwz     r3,0(r9)
>    c:	7c 63 20 38 	and     r3,r3,r4
>   10:	7c 63 22 78 	xor     r3,r3,r4
>   14:	7c 63 00 34 	cntlzw  r3,r3
>   18:	54 63 d9 7e 	srwi    r3,r3,5
>   1c:	78 63 07 e0 	clrldi  r3,r3,63
>   20:	4e 80 00 20 	blr
>   24:	60 00 00 00 	nop
>   28:	60 00 00 00 	nop
>   2c:	e9 2a 00 20 	ld      r9,32(r10)
>   30:	80 69 00 00 	lwz     r3,0(r9)
>   34:	4b ff ff d8 	b       0xc
>   38:	60 00 00 00 	nop
>   3c:	7c a5 00 34 	cntlzw  r5,r5
>
> Code starting with the faulting instruction
> ===========================================
>    0:	80 69 00 00 	lwz     r3,0(r9)

> [    2.644031] GPR08: 0000000000000001 0000000000000000 c00000000228fcc0 0000000044222288

So R9 is NULL, R10 is the domain pointer.


>    4:	4b ff ff d8 	b       0xffffffffffffffdc
>    8:	60 00 00 00 	nop
>    c:	7c a5 00 34 	cntlzw  r5,r5
> [    2.644769] ---[ end trace 0000000000000000 ]---
>
>
> (That's the bug splat from the bug report piped through
> scripts/decode_stacktrace.sh)
>
> The kernel has CONFIG_PCI_MSI_ARCH_FALLBACKS=y, so the first hunk
> shouldn't change anything.

Correct. But the Ooops is in the unchanged code part of
pci_msi_domain_supports().

> so the trapping happens in drivers/pci/msi/irqdomain.c:366 which is:
>
> 365	                info = domain->host_data;
> 366	                supported = info->flags;
>
> According to the register dump domain == r10 == NULL, but then this code

No. You are looking at the wrong register set. The second one is the
user space register set from the syscall entry. 

R10 contains the domain pointer and R9 is NULL, which does not make any
sense.

On 6.12 power64 still uses the global PCI/MSI domain model. According to
the splat this is pseries so the global PCI/MSI domain is created in
__pseries_msi_allocate_domains() via pci_msi_create_irq_domain(). The
latter takes a pointer to

       static struct msi_domain_info_pseries_msi_domain_info;

which is assigned to the global PCI/MSI domain::host_data.

Upstream got rid of that and uses per device domains, so it might have
been magically fixed by now, but I doubt it:

That new check in __pci_enable_msi_range() is benign as the actual
allocation code further down relies on domain::host_data being a valid
pointer as well.

It might not reach that point due to the subsequent checks, but if the
PCI device has pdev::dev::msi::domain populated, then this has to be
either a global PCI/MSI domain or a MSI parent domain. Both have
domain::host_data populated with a msi_domain_info pointer.

Something is mighty fishy here.

Aaron, can you please apply the patch below and see whether it fixes the
issue and provide the dmesg with the output of those pr_warn()'s?

The other information which would be useful: When you boot a kernel with
the commit reverted and look at that OHCI controller with lspci -vvv
then you should see whether it has MSI enabled or not. If it has MSI
enabled, then please provide the output of

   /sys/kernel/debug/irq/irqs/$IRQNR

You need to enable CONFIG_GENERIC_IRQ_DEBUGFS for that.

And that's actually useful for the debug patch below too because you can
then look at the domain name output and gather more information from

     /sys/kernel/debug/irq/domains/$NAME

Thanks,

        tglx
---
 drivers/pci/msi/irqdomain.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- a/drivers/pci/msi/irqdomain.c
+++ b/drivers/pci/msi/irqdomain.c
@@ -115,6 +115,8 @@ struct irq_domain *pci_msi_create_irq_do
 					     struct msi_domain_info *info,
 					     struct irq_domain *parent)
 {
+	struct irq_domain *domain;
+
 	if (WARN_ON(info->flags & MSI_FLAG_LEVEL_CAPABLE))
 		info->flags &= ~MSI_FLAG_LEVEL_CAPABLE;
 
@@ -135,7 +137,12 @@ struct irq_domain *pci_msi_create_irq_do
 	/* Let the core update the bus token */
 	info->bus_token = DOMAIN_BUS_PCI_MSI;
 
-	return msi_create_irq_domain(fwnode, info, parent);
+	domain = msi_create_irq_domain(fwnode, info, parent);
+	if (domain) {
+		pr_warn("Created global PCI/MSI domain %lx %s flags: %x\n",
+			(unsigned long)domain, domain->name, domain->flags);
+	}
+	return domain;
 }
 EXPORT_SYMBOL_GPL(pci_msi_create_irq_domain);
 
@@ -356,6 +363,12 @@ bool pci_msi_domain_supports(struct pci_
 		return false;
 	}
 
+	if (!domain->host_data) {
+		pr_warn("Device MSI domain %lx %s %x lacks host data\n",
+			(unsigned long)domain, domain->name, domain->flags);
+		return false;
+	}
+
 	if (!irq_domain_is_msi_parent(domain)) {
 		/*
 		 * For "global" PCI/MSI interrupt domains the associated


  parent reply	other threads:[~2026-04-22 21:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 11:57 [RFC PATCH] riscv: Fix PCI warning by enabling PCI_MSI_ARCH_FALLBACKS Alexandre Ghiti
2024-12-13 13:12 ` Thomas Gleixner
2024-12-13 13:51   ` Alexandre Ghiti
2024-12-14 11:50     ` [Patch] PCI/MSI: Handle lack of irqdomain gracefully Thomas Gleixner
2024-12-17 13:08       ` [tip: irq/urgent] " tip-bot2 for Thomas Gleixner
2025-02-03 19:16       ` [Patch] " patchwork-bot+linux-riscv
2026-03-11 11:22       ` Uwe Kleine-König
2026-04-22  8:50         ` Thorsten Leemhuis
2026-04-22 15:07           ` Aaron D. Johnson
2026-04-22 19:52           ` Thomas Gleixner
2026-04-22 21:22         ` Thomas Gleixner [this message]
2026-04-22 22:34           ` Aaron D. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87qzo61yik.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=1127635@bugs.debian.org \
    --cc=alexghiti@rivosinc.com \
    --cc=anup@brainfault.org \
    --cc=debbugreporter@fnord.greeley.co.us \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=regressions@lists.linux.dev \
    --cc=sunilvl@ventanamicro.com \
    --cc=u.kleine-koenig@baylibre.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox