lkml.org 
[lkml]   [2019]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 3/3] genirq/irqdomain: Detect type race in irq_create_fwspec_mapping()
Date
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.
\
 
 \ /
  Last update: 2019-09-20 18:15    [W:0.262 / U:0.848 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site