The previous version of this patch has two related bugs:
- 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.

The solution is not ideal because it may lie about the effective
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/

Signed-off-by: Radu Rendec <rrendec@redhat.com>
---
 kernel/irq/chip.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 433f1dd2b0ca7..35bc17bc369e0 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1493,6 +1493,8 @@ int irq_chip_redirect_set_affinity(struct irq_data *data, const struct cpumask *
 	struct irq_redirect *redir = &irq_data_to_desc(data)->redirect;
 
 	WRITE_ONCE(redir->target_cpu, cpumask_first(dest));
+	irq_data_update_effective_affinity(data, dest);
+
 	return IRQ_SET_MASK_OK;
 }
 EXPORT_SYMBOL_GPL(irq_chip_redirect_set_affinity);
-- 
2.52.0

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

Hello, Thomas!

On Sun, 2026-01-11 at 22:52 +0100, Thomas Gleixner wrote:
> 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
> 
> [snip]
> 
> It also lacks a 'Fixes:' tag as the code is already merged, no?
> 
> 
> [snip]

Apologies, and thanks a lot for taking the time to provide such
detailed feedback!

I mistakenly assumed the original commit could still be *amended*, and
the format I used was a (failed) attempt at asking that. I didn't
realize the commit was immutable once included in the tip tree, and
didn't pay much attention to the commit message because I thought it
would be discarded anyway while amending.

In my defense, $subject: "fixup! <original commit subject>" is a format
recognized by `git rebase` and used on some subsystems to fix already
accepted patches *before* they are merged upstream. It just doesn't
apply here. Lesson learned!

I will re-send it using the standard format for fixing a commit that's
already merged, and follow all the suggestions you made.

-- 
Best regards,
Radu