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.