linux-kernel - Re: IRQ thread timeouts and affinity

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: <86qzvcxi3j.wl-maz@kernel.org>
Date: Thu, 09 Oct 2025 15:30:56 +0100
From: Marc Zyngier <maz@...nel.org>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	linux-tegra@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: IRQ thread timeouts and affinity

Hi Thierry,

On Thu, 09 Oct 2025 12:38:55 +0100,
Thierry Reding <thierry.reding@...il.com> wrote:
> 
> Which brings me to the actual question: what is the right way to solve
> this? I had, maybe naively, assumed that the default CPU affinity, which
> includes all available CPUs, would be sufficient to have interrupts
> balanced across all of those CPUs, but that doesn't appear to be the
> case. At least not with the GIC (v3) driver which selects one CPU (CPU 0
> in this particular case) from the affinity mask to set the "effective
> affinity", which then dictates where IRQs are handled and where the
> corresponding IRQ thread function is run.

There's a (GIC-specific) answer to that, and that's the "1 of N"
distribution model. The problem is that it is a massive headache (it
completely breaks with per-CPU context).

We could try and hack this in somehow, but defining a reasonable API
is complicated. The set of CPUs receiving 1:N interrupts is a *global*
set, which means you cannot have one interrupt targeting CPUs 0-1, and
another targeting CPUs 2-3. You can only have a single set for all 1:N
interrupts. How would you define such a set in a platform agnostic
manner so that a random driver could use this? I definitely don't want
to have a GIC-specific API.

Overall, there is quite a lot of work to be done in this space: the
machine I'm typing this from doesn't have affinity control *at
all*. Any interrupt can target any CPU, and if Linux doesn't expect
that, tough.  Don't even think of managed interrupts on that sort of
systems...

	M.

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