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: <878qe7rn9c.ffs@tglx>
Date: Fri, 09 Jan 2026 13:20:15 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Luigi Rizzo <lrizzo@...gle.com>
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 Thu, Jan 08 2026 at 22:55, Luigi Rizzo wrote:

> On Thu, Jan 8, 2026 at 10:32 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> On Mon, Dec 22 2025 at 16:16, Marc Zyngier wrote:
>> >> > > Once we remove the costly readback, is there any remaining reason
>> >> > > to overwrite [un]mask_irq() with irq_chip_[un]mask_parent() ?
>> >> >
>> >> > So you are effectively not masking at all and just rely on hope
>> >> > instead. I have the utmost confidence in this sort of stuff. Totally.
>> >>
>> >> I don't understand the above comment.
>> >> Masking happens as a result of the PCIe write,
>> >> which will eventually reach the device. The presence of the
>> >> readback does nothing to accelerate the landing of the write.
>> >
>> > It doesn't accelerate it. It *guarantees* that the write is observed
>> > and has taken effect. It acts as a completion barrier. Without it, the
>> > write can be buffered at an arbitrary location in the interconnect, or
>> > stored in the device but not acted upon.
>> >
>> > What you have here is the equivalent of throwing a message in a bottle
>> > at sea, and expecting a guaranteed reply.
>>
>>   https://xkcd.com/3150/
>
>
> The irony is that the change I was commenting about
> completely removes masking at the PCI level (ie not even the bottle).
>
> 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.

> - 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 and unmask() does not
require an guarantee like mask() does.

> - unless I am missing some cases, outside of moderation
>   the mask() is only ever called on interrupt
>   shutdown or on affinity migration.

Correct.

Thanks,

        tglx