linux-kernel - Re: [patch 1/2] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAMOZA0JEia2Yz2HC=xz+LbsCPNHfx_KPZx41ohHns0zguQd+rw@mail.gmail.com>
Date: Fri, 9 Jan 2026 14:00:48 +0100
From: Luigi Rizzo <lrizzo@...gle.com>
To: Thomas Gleixner <tglx@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, bhelgaas@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/2] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT
 flag

On Fri, Jan 9, 2026 at 1:20 PM Thomas Gleixner <tglx@...nel.org> wrote:
>
> On Thu, Jan 08 2026 at 22:55, Luigi Rizzo wrote:
>
> > ...
> > Anyways, coming back to my secondary point,
> > which is what does the readback give us, I want to repeat my arguments:
> >
> > - knowing that the mask() has landed on the device does not guarantee
> >   that there was not a previously generated MSIx write in transit.
> >   So even with the readback, the interrupt subsystem must be
> >   prepared to handle the pending interrupt (which of course it is).
>
> That's not the point. The point is that _after_ the mask has reached the
> device it is guaranteed that no further interrupts are generated until
> unmask() is invoked. That's what is required e.g. for writing the MSI
> message to the device.

I keep hearing about this guarantee, which is surely true, but I argue that
it is useless both during normal activity (when interrupts may be
occasionally masked during affinity changes) and at shutdown
(when there is a lot more additional state cleanup done on
the device, which insures that there are no more interrupts,
save the one(s) happening between the mask() write and readback,
which we have no way to block, anyways (and may fire on the CPU at
some unspecified time, even after the readback, because that does not
control the pipeline from the device to the interrupt controller etc.),
and that the kernel stack is well equipped to handle and ignore.

But maybe I am missing some context, so can you explain what do you mean by
"required e.g. for writing the MSI message to the device" ?
(both parts, what is "writing a MSI message to the device" and
what makes it a requirement to have interrupts masked).

The only, weak, justification that Gemini gives for masking is that
"if we leave interrupts unmasked before doing a function level reset, the
device might send a malformed TLP", but if that is the case (asynchronous
reset breaking an in flight TLP??), that's a hardware error that is trivially
detected and recovered from.

>
> > - if the concern is that the mask() write may never reach the
> >   device, there is no reason to expect that the unmask()
> >   will be treated differently. Yet, the unmask() has no readback
>
> It will reach the device at some random point in time. The queued writes
> are not lost. They are drained at some point

Exactly my point, queued writes are not lost and will eventually land.

> and unmask() does not
> require an guarantee like mask() does.

Again, I have seen no explanation so far on why the mask requires a guarantee,
and as I have tried to explain, the unavoidable stray interrupts
generated before the readback
are as bad (or actually as harmless) as the ones that we avoid with
the readback.

cheers
luigi