Jan Kiszka wrote:

I happened to stumble over this comment[1]. It made me curious,
especially as it is not totally correct (the loop is executed in IRQ-off
context, thus it *is* timecritical).

Critical should be understood here in the sense that IRQs are off while the loop workload is high, which is fortunately not the case. Hence the comment.

While thinking about the possibility to convert the hard IRQ lock
protection of kheapq into some Linux mutex or whatever, I analysed the
contexts the users of this queue (__validate_heap_addr/xnheap_ioctl,
xnheap_init_shared, xnheap_destroy_shared) execute in. Basically, it is
Linux/secondary mode, but there are unfortunate exceptions:

rt_heap_delete(): take nklock[2], then call xnheap_destroy_shared()[3].
The latter will call __unreserve_and_free_heap()[4] which calls Linux
functions like vfree()[5] or kfree()[6] -- I would say: not good! At
least on SMP we could easily get trapped by non-deterministic waiting on
Linux spinlocks inside those functions.

The same applies to rt_queue_delete()[7].

Good spot. Better not calling the heap deletion routines under nklock protection in the first place. The committed fix does just that for both rt_heap_delete and rt_queue_delete.

To clarify the relevance: These issues only concern the native skin, and
they only hit during init and cleanup. Anyway, should get fixed.




Xenomai-core mailing list



Reply via email to