linux-kernel - Re: [PATCH] fixup! genirq: Add interrupt redirection infrastructure

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: <87fr8bg6lv.ffs@tglx>
Date: Sun, 11 Jan 2026 22:52:12 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Radu Rendec <rrendec@...hat.com>
Cc: Manivannan Sadhasivam <mani@...nel.org>, Daniel Tsai
 <danielsftsai@...gle.com>, Marek Behún <kabel@...nel.org>,
 Krishna
 Chaitanya Chundru <quic_krichai@...cinc.com>, Bjorn Helgaas
 <bhelgaas@...gle.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Wilczyński
 <kwilczynski@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Jingoo Han <jingoohan1@...il.com>, Brian Masney <bmasney@...hat.com>, Eric
 Chanudet <echanude@...hat.com>, Alessandro Carminati
 <acarmina@...hat.com>, Jared Kangas <jkangas@...hat.com>, Jon Hunter
 <jonathanh@...dia.com>, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, x86@...nel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH] fixup! genirq: Add interrupt redirection infrastructure

Radu!

Thanks for taking care of this, but this is not really the way how it
works.

$subject: fixup!.... is neither a valid nor a useful subject line.

$subject is documented to be a concise summary of the change at hand, so
in this case this should be something like:

   [PATCH] genirq: Update effective affinity for redirected interrupts

See?

On Fri, Jan 09 2026 at 12:52, Radu Rendec wrote:
> The previous version of this patch has two related bugs:

The previous version of which patch? The patch at hand does not have a
previous version, right?

> - irq_chip_redirect_set_affinity() doesn't update the effective affinity
>   mask, which triggers the warning in irq_validate_effective_affinity().
>   This bug was reported at [1].
> - As a result, the cpumask_test_cpu(smp_processor_id(), m) condition in
>   demux_redirect_remote() is always false, and the interrupt is always
>   redirected, even if it's already running on the target CPU.

How are those two bugs? It's only one because the missing update causes
the malfunction in demux_redirect_remote(), no?

> The solution is not ideal because it may lie about the effective

Which solution? Care to read this change log again and figure out what
"the solution" means? You fail to describe the solution before you
describe it being non ideal...

> affinity of the demultiplexed ("child") interrupt. If the requested
> affinity mask includes multiple CPUs, the effective affinity, in
> reality, is the intersection between the requested mask and the
> demultiplexing ("parent") interrupt's effective affinity mask, plus
> the first CPU in the requested mask.
>
> Accurately describing the effective affinity of the demultiplexed
> interrupt is not trivial because it requires keeping track of the
> demultiplexing interrupt's effective affinity. That is tricky in the
> context of CPU hot(un)plugging, where interrupt migration ordering is
> not guaranteed. The solution in the original version of the patch,
> which stored the first CPU of the demultiplexing interrupt's effective
> affinity in the `target_cpu` field, has its own drawbacks and
> limitations.
>
> [1] https://lore.kernel.org/all/44509520-f29b-4b8a-8986-5eae3e022eb7@nvidia.com/

This wants to be a Closes: https://... tag which makes that [1]
reference superflouous when you describe the problem coherently.

It also lacks a 'Fixes:' tag as the code is already merged, no?

> Signed-off-by: Radu Rendec <rrendec@...hat.com>

Read 'git log kernel/irq/' output and search for 'Closes:' tags in the
commit messages and you get the idea.

Thanks,

        tglx