Nope, good spot, that could indeed happen in SMP configs. The code is
expected to shut the given interrupt source _before_ calling
rthal_irq_release(). But, the root of the problem is that
rthal_irq_release() doesn't make sure that all _pending_ IRQs from the
given kind are synchronized before processing. We need the equivalent of
Linux's synchronize_irq() here, and I would tend to implement this in
the Adeos layer directly, in ipipe_virtualize_irq() for the NULL handler
case, since it's a matter of general consistency.
Yep, I thought about the analogue of Linux's synchronize_irq() too.
I guess, what we need to provide is the guarantee that the "cookie" argument (as well as a "handler") remains valid as long as there is a given irq handler in execution.
i.e.
o ipipe_virtualize_irq(THIS_IRQ, handler=NULL, cookie=NULL) call _removes_ the IPIPE_HANDLE_FLAG so that new occurences of the THIS_IRQ is no more accepted for the given domain;
o then ipipe_virtualize_irq is buzy waiting (ipipe_synchronize_irq() or smth like this) until the active ipd->irqs[THIS_IRQ].handler() is completed.
If there is not currently active handler we may drop all cpudata->irq_pending_hits for THIS_IRQ to zero. But ipipe_sync_stage() should check for IPIPE_HANDLE_FLAG then since this is a sign that a given irq is no more handled (even if there are some pending ones).
o as a final step, ipd->irqs[THIS_IRQ].handler/cookie are set to zero.
Ok, repeating myself, the main idea is to keep the "cookie" unchanged as long as the corresponding handler is active. This would partialy resolve the sync. problem I have got on the nucleus layer.
--
Best regards,
Dmitry Adamushko
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
