linux-kernel - Re: [PATCH v2 5/5] irqchip/gic-v3-its: Use allocation size from the prepare call

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: <86v7pwekum.wl-maz@kernel.org>
Date: Mon, 19 May 2025 15:28:01 +0100
From: Marc Zyngier <maz@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Sascha Bischoff
 <sascha.bischoff@....com>,
	Timothy Hayes <timothy.hayes@....com>
Subject: Re: [PATCH v2 5/5] irqchip/gic-v3-its: Use allocation size from the prepare call

On Mon, 19 May 2025 13:16:58 +0100,
Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> On Mon, May 19 2025 at 11:15, Marc Zyngier wrote:
> > On Sun, 18 May 2025 19:53:42 +0100,
> > Thomas Gleixner <tglx@...utronix.de> wrote:
> >> 
> >> On Tue, May 13 2025 at 17:31, Marc Zyngier wrote:
> >> 
> >> > Now that .msi_prepare() gets called at the right time and not
> >> > with semi-random parameters, remove the ugly hack that tried
> >> > to fix up the number of allocated vectors.
> >> >
> >> > It is now correct by construction.
> >> 
> >> FWIW, while looking at something related, it occured to me that with
> >> this change you can enable MSI_FLAG_PCI_MSIX_ALLOC_DYN now on GIC ITS.
> >
> > Maybe. It is rather unclear to me what this "dynamic allocation"
> > actually provides in terms of guarantees to the endpoint driver.
> 
> It allows the driver to avoid allocating a gazillion of interrupts
> upfront during initialization. Instead it can allocate them on demand,
> when e.g. a queue is initialized. Of course that means that such an
> allocation can fail, but so can request_irq() and other things. I'm not
> sure what you mean with guarantees here.

What is the endpoint driver allowed to expect in terms of continuity
of allocation in the IRQ space? If this is solely limited to MSI-X,
then the answer probably is "none whatsoever", and the driver should
only manage the MSI descriptor index.

Can any other MSI-like mechanism end-up with multiple allocations and
require extra alignment/contiguity guarantees in the hwirq space, more
or less similar to what MultiMSI requires? Because that'd be much
harder to provide.

	M.

-- 
Without deviation from the norm, progress is not possible.