linux-kernel - Re: [PATCH v3 3/3] PCI: dwc: Enable MSI affinity support

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: <87h5s7bb5s.ffs@tglx>
Date: Tue, 27 Jan 2026 11:30:23 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Radu Rendec <rrendec@...hat.com>, Jon Hunter <jonathanh@...dia.com>,
 Manivannan Sadhasivam <mani@...nel.org>
Cc: Daniel Tsai <danielsftsai@...gle.com>, Marek Behún
 <kabel@...nel.org>,
 Krishna Chaitanya Chundru <quic_krichai@...cinc.com>, Bjorn Helgaas
 <bhelgaas@...gle.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Wilczyński
 <kwilczynski@...nel.org>, Lorenzo
 Pieralisi <lpieralisi@...nel.org>, Jingoo Han <jingoohan1@...il.com>, Brian
 Masney <bmasney@...hat.com>, Eric Chanudet <echanude@...hat.com>,
 Alessandro Carminati <acarmina@...hat.com>, Jared Kangas
 <jkangas@...hat.com>, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, "linux-tegra@...r.kernel.org"
 <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] PCI: dwc: Enable MSI affinity support

On Mon, Jan 26 2026 at 17:26, Radu Rendec wrote:
> On Mon, 2026-01-26 at 22:07 +0000, Jon Hunter wrote:
>> > Jon, can you please validate that this happens as well on
>> > 
>> >       git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/msi
>> 
>> 
>> I tried this branch and I see suspend failing with that branch too. If I 
>> revert this change on top of your branch or -next, I don't see any 
>> problems.
>
> The closest hardware I have access to is Jetson Xavier NX, and you
> already mentioned you couldn't reproduce the issue there (and it looks
> like I can't even get a hold of that board anyway). So I'm going to ask
> you to test a few more things for me.
>
> Can you please apply the patch below on top of the previous one I sent?
> The suspect is the spinlock lock in irq_migrate_all_off_this_cpu(),
> although I can't think of any reason why it shouldn't be free. But I
> don't have any better idea, and I would like to narrow down the spot
> where hotplug gets stuck.

Can we please take a step back and think about what is actually
different when this change is in effect instead of halluzinating about
completely unrelated spinlocks?

Without this change the interrupt is ignored in the hotplug migration
because it has MSI_FLAG_NO_AFFINITY set.

Now with this new magic in place the following happens:

migrate_one_irq()
   ...
   irq_do_set_affinity()
      chip->irq_set_affinity()                // --> msi_domain_set_affinity()
         parent->chip->irq_set_affinity()     // --> irq_chip_redirect_set_affinity()
            update target_cpu/effective mask; // Benign
         ...
         irq_chip_write_msi_msg()             // --> pci_msi_domain_write_msg()
  
I'm pretty sure that this write screws things up because the
devices/busses are already frozen. It simply hangs there.

Usually this is prevented by this check in pci_msi_domain_write_msg():

        if (dev->current_state != PCI_D0 || pci_dev_is_disconnected(dev))
        	do_nothing();
        else ...

As the boot log contains this:

[   44.101151] tegra194-pcie 14100000.pcie: Link didn't transition to L2 state
[   44.110764] Disabling non-boot CPUs ...

... I suspect that there is some weirdness going on with this PCIe
controller which subsequently screws up the check.

The below untested hack should confirm that theory.

Thanks,

        tglx
---
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -672,7 +672,11 @@ int msi_domain_set_affinity(struct irq_d
 	if (ret >= 0 && ret != IRQ_SET_MASK_OK_DONE) {
 		BUG_ON(irq_chip_compose_msi_msg(irq_data, msg));
 		msi_check_level(irq_data->domain, msg);
-		irq_chip_write_msi_msg(irq_data, msg);
+		// Hack alert
+		struct irq_desc *desc = irq_data_to_desc(irq_data);
+
+		if (!(desc->istate & IRQS_SUSPENDED))
+			irq_chip_write_msi_msg(irq_data, msg);
 	}
 
 	return ret;