* [PATCH] genirq: Update effective affinity for redirected interrupts
@ 2026-01-12 21:14 Radu Rendec
2026-01-12 21:32 ` Jon Hunter
2026-01-13 9:05 ` [tip: irq/msi] " tip-bot2 for Radu Rendec
0 siblings, 2 replies; 3+ messages in thread
From: Radu Rendec @ 2026-01-12 21:14 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Manivannan Sadhasivam, Daniel Tsai, Marek Behún,
Krishna Chaitanya Chundru, Bjorn Helgaas, Rob Herring,
Krzysztof Wilczyński, Lorenzo Pieralisi, Jingoo Han,
Brian Masney, Eric Chanudet, Alessandro Carminati, Jared Kangas,
Jon Hunter, linux-pci, linux-kernel, x86, linux-tegra
For redirected interrupts, irq_chip_redirect_set_affinity() does not
update the effective affinity mask, which then triggers the warning in
irq_validate_effective_affinity(). Also, because the effective affinity
mask is empty, 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.
Set the effective affinity mask to be the same as the requested affinity
mask. It's worth noting that irq_do_set_affinity() filters out offline
CPUs before calling chip->irq_set_affinity() (unless `force` is set), so
the mask passed to irq_chip_redirect_set_affinity() is already filtered.
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 initial version of the fixed patch,
which stored the first CPU of the demultiplexing interrupt's effective
affinity in the `target_cpu` field, has its own drawbacks and
limitations.
Fixes: fcc1d0dabdb6 ("genirq: Add interrupt redirection infrastructure")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Closes: 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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] genirq: Update effective affinity for redirected interrupts
2026-01-12 21:14 [PATCH] genirq: Update effective affinity for redirected interrupts Radu Rendec
@ 2026-01-12 21:32 ` Jon Hunter
2026-01-13 9:05 ` [tip: irq/msi] " tip-bot2 for Radu Rendec
1 sibling, 0 replies; 3+ messages in thread
From: Jon Hunter @ 2026-01-12 21:32 UTC (permalink / raw)
To: Radu Rendec, Thomas Gleixner
Cc: Manivannan Sadhasivam, Daniel Tsai, Marek Behún,
Krishna Chaitanya Chundru, Bjorn Helgaas, Rob Herring,
Krzysztof Wilczyński, Lorenzo Pieralisi, Jingoo Han,
Brian Masney, Eric Chanudet, Alessandro Carminati, Jared Kangas,
linux-pci, linux-kernel, x86, linux-tegra
On 12/01/2026 21:14, Radu Rendec wrote:
> For redirected interrupts, irq_chip_redirect_set_affinity() does not
> update the effective affinity mask, which then triggers the warning in
> irq_validate_effective_affinity(). Also, because the effective affinity
> mask is empty, 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.
>
> Set the effective affinity mask to be the same as the requested affinity
> mask. It's worth noting that irq_do_set_affinity() filters out offline
> CPUs before calling chip->irq_set_affinity() (unless `force` is set), so
> the mask passed to irq_chip_redirect_set_affinity() is already filtered.
>
> 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 initial version of the fixed patch,
> which stored the first CPU of the demultiplexing interrupt's effective
> affinity in the `target_cpu` field, has its own drawbacks and
> limitations.
>
> Fixes: fcc1d0dabdb6 ("genirq: Add interrupt redirection infrastructure")
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Closes: 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);
This is working for me ...
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Thanks
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 3+ messages in thread* [tip: irq/msi] genirq: Update effective affinity for redirected interrupts
2026-01-12 21:14 [PATCH] genirq: Update effective affinity for redirected interrupts Radu Rendec
2026-01-12 21:32 ` Jon Hunter
@ 2026-01-13 9:05 ` tip-bot2 for Radu Rendec
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot2 for Radu Rendec @ 2026-01-13 9:05 UTC (permalink / raw)
To: linux-tip-commits
Cc: Jon Hunter, Radu Rendec, Thomas Gleixner, x86, linux-kernel
The following commit has been merged into the irq/msi branch of tip:
Commit-ID: df439718afaf23b5aa7b5711b6c14e87b5836cae
Gitweb: https://git.kernel.org/tip/df439718afaf23b5aa7b5711b6c14e87b5836cae
Author: Radu Rendec <rrendec@redhat.com>
AuthorDate: Mon, 12 Jan 2026 16:14:02 -05:00
Committer: Thomas Gleixner <tglx@kernel.org>
CommitterDate: Tue, 13 Jan 2026 09:59:28 +01:00
genirq: Update effective affinity for redirected interrupts
For redirected interrupts, irq_chip_redirect_set_affinity() does not
update the effective affinity mask, which then triggers the warning in
irq_validate_effective_affinity(). Also, because the effective affinity
mask is empty, 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.
Set the effective affinity mask to be the same as the requested affinity
mask. It's worth noting that irq_do_set_affinity() filters out offline
CPUs before calling chip->irq_set_affinity() (unless `force` is set), so
the mask passed to irq_chip_redirect_set_affinity() is already filtered.
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 initial version of the fixed patch,
which stored the first CPU of the demultiplexing interrupt's effective
affinity in the `target_cpu` field, has its own drawbacks and
limitations.
Fixes: fcc1d0dabdb6 ("genirq: Add interrupt redirection infrastructure")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Radu Rendec <rrendec@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260112211402.2927336-1-rrendec@redhat.com
Closes: https://lore.kernel.org/all/44509520-f29b-4b8a-8986-5eae3e022eb7@nvidia.com/
---
kernel/irq/chip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 433f1dd..35bc17b 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);
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-01-13 9:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-01-12 21:14 [PATCH] genirq: Update effective affinity for redirected interrupts Radu Rendec
2026-01-12 21:32 ` Jon Hunter
2026-01-13 9:05 ` [tip: irq/msi] " tip-bot2 for Radu Rendec
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®