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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAMOZA0LzVSDc+HVA36WeRHciw3uXz62eN5rYQQ3MdP_YBHFROQ@mail.gmail.com>
Date: Thu, 8 Jan 2026 22:55:16 +0100
From: Luigi Rizzo <lrizzo@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
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 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).

- 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

- unless I am missing some cases, outside of moderation
  the mask() is only ever called on interrupt
  shutdown or on affinity migration. so the frequency should
  be negligible and the benefits of the optimization probably
  hardly measurable (which is also the reason I don't
  particularly care about removing the writeback, I only
  wanted to clarify what it gives)

cheers
luigi