Am 28.10.2010 21:34, Philippe Gerum wrote:
> On Thu, 2010-10-28 at 21:15 +0200, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles,
>>>
>>> I happened to come across rthal_mark_irq_disabled/enabled on arm. On
>>> first glance, it looks like these helpers manipulate irq_desc::status
>>> non-atomically, i.e. without holding irq_desc::lock. Isn't this fragile?
>>
>> I have no idea. How do the other architectures do? As far as I know,
>> this code has been copied from there.
> 
> Other archs do the same, simply because once an irq is managed by the
> hal, it may not be shared in any way with the regular kernel. So locking
> is pointless.

Indeed, I missed that all the other archs have this uninlined in hal.c.

However, this leaves at least a race between xnintr_disable/enable and
XN_ISR_PROPAGATE (ie. the related Linux path) behind. Not sure if it
matters practically - but risking silent breakage for this micro
optimization? Is disabling/enabling really in the highly
latency-critical anywhere? Otherwise, I would suggest to just plug this
by adding the intended lock for this field.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to