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

[Thomas Gleixner <tglx@kernel.org>]

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@redhat.com>

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

Thanks,

        tglx