Hi Marc,
On 20/09/2019 17:52, Marc Zyngier wrote:
If two irq_create_mapping() calls perform a mapping of the same hwirq on two CPU cores in parallel they both will get 0 from irq_find_mapping(), both will allocate unique virq using irq_domain_alloc_descs() and both will finally irq_domain_associate() it. Giving different virq numbers to their callers.
In practice the first caller is usually an interrupt controller driver and the seconds is some device requesting the interrupt providede by the above interrupt controller.
I disagree with this "In practice". An irqchip controller should *very rarely* call irq_create_mapping on its own. It usually indicates some level of brokenness, unless the mapped interrupt is exposed by the irqchip itself (the GIC maintenance interrupt, for example).
I also didn't understand the reason the irqchip in question calls irq_create_mapping(), but as 9 upstream irqchips do this as well I was not really interested in the reasons for this.
In this case either the interrupt controller driver configures virq which is not the one being "associated" with hwirq, or the "slave" device requests the virq which is never being triggered.
Why should the interrupt controller configure that interrupt? On any sane platform, the mapping should be created by the user of the interrupt, and not by the provider.
This doesn't mean we shouldn't fix the irqdomain races, but I tend to disagree with the analysis here.
That's in fact what happens in our case and may happen with 9 upstream irqchips as well. Same race would however happen with any IRQ client driver calling of_irq_get(), if they share same HW IRQ line.