Messages in this thread | | | Subject | Re: [PATCH 2/3] genirq/irqdomain: Re-check mapping after associate in irq_create_mapping() | From | Alexander Sverdlin <> | Date | Wed, 8 Jan 2020 16:07:35 +0100 |
| |
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?
-- Best regards, Alexander Sverdlin.
| |