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.
