Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
From: Saidi, Ali <hidden>
Date: 2020-06-01 00:10:14
Also in:
lkml
Marc,
On May 31, 2020, at 6:10 AM, Marc Zyngier [off-list ref] wrote:quoted
Not great indeed. But this is not, as far as I can tell, a GIC driver problem. The semantic of activate/deactivate (which maps to started/shutdown in the IRQ code) is that the HW resources for a given interrupt are only committed when the interrupt is activated. Trying to perform actions involving the HW on an interrupt that isn't active cannot be guaranteed to take effect.
Yes, then it absolutely makes sense to address it outside the GIC.
quoted hunk ↗ jump to hunk
quoted
I'd rather address it in the core code, by preventing set_affinity (and potentially others) to take place when the interrupt is not in the STARTED state. Userspace would get an error, which is perfectly legitimate, and which it already has to deal with it for plenty of other reasons.How about this:diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 453a8a0f4804..1a2ac1392c0f 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c@@ -147,7 +147,8 @@ cpumask_var_t irq_default_affinity;static bool __irq_can_set_affinity(struct irq_desc *desc) { if (!desc || !irqd_can_balance(&desc->irq_data) || - !desc->irq_data.chip || !desc->irq_data.chip->irq_set_affinity) + !desc->irq_data.chip || !desc->irq_data.chip->irq_set_affinity || + !irqd_is_started(&desc->irq_data)) return false; return true; }
Confirmed I can’t reproduce the issue with your fix. Thanks, Ali _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel