Hello Marc,
On 20/09/2019 17:52, Marc Zyngier wrote:
On 12/09/2019 10:44, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
From: Alexander Sverdlin alexander.sverdlin@nokia.com
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).
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.
would you have time to review v2 of this series?