Messages in this thread | | | From | "Sverdlin, Alexander (Nokia - DE/Ulm)" <> | Subject | Re: [PATCH 3/3] genirq/irqdomain: Detect type race in irq_create_fwspec_mapping() | Date | Fri, 20 Sep 2019 16:14:11 +0000 |
| |
Hi!
On 20/09/2019 18:07, Marc Zyngier wrote: >> irq_create_fwspec_mapping() can race with itself during IRQ trigger type >> configuration. Possible scenarios include: >> >> - Mapping exists, two irq_create_fwspec_mapping() running in parallel do >> not detect type mismatch, IRQ remains configured with one of the >> different trigger types randomly >> - Second call to irq_create_fwspec_mapping() sees existing mapping just >> created by first call, but earlier irqd_set_trigger_type() call races >> with later irqd_set_trigger_type() => totally undetected, IRQ type >> is being set randomly to either one or another type > Is that an actual thing? Frankly, the scenario you're describing here > seems to carry the hallmarks of a completely broken system. Can you > point at a system supported in mainline that would behave as such?
Briefly speaking, this race is about not-complaining in case of a broken device tree. This is not something purely theoretical. I don't know if DTs under arch/arm/boot/dts are all correct, but I saw a lot DTs from silicone vendors and very little of them were 100% correct.
In other words, this patch repairs error-handling. With 100% correct DTs (or ACPI tables, have you seen one 100% correct BTW? :)) it's not required.
-- Best regards, Alexander Sverdlin.
| |