On 09/01/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
> Dmitry Adamushko wrote:
> > Hi everybody,
> > I'm presenting it one last time as a draft, so it's a right time to give
> > the remarks concerning design/implementation issues for all interested
> > parties.
> > Any feedback is wellcome.
> Maybe I missed some recent changes in Xenomai HAL or Adeos, in which
> case, please forget my remark, but calling xnarch_hook_irq,
> i.e. rthal_irq_request when nklock is locked, irq off, may lead to
> deadlock on multi-processor machines. The situation is (or used to be)
> as follows:
> holds the nklock
> calls rthal_irq_request, which calls ipipe_critical_enter, which:
> triggers the critical IPI
> spins, waiting for other CPUs to enter __ipipe_do_critical_sync
> spins on nklock, irq off
> never handles the critical IPI, because irqs are off
Nop, your remark is actually right to the place. I had some doubts
regarding the use of nklock here but, flankly, I didn't even consider
that possible deadlock. Thanks for a hint.
> I only skimmed over the discussion about ipipe_virtualize_irq_from. I do
> not know if it finally flushes all pending interrupts an all CPUs when
> called with a NULL handler. But if it does, the call to
> xnintr_shirq_spin seems redundant in xnintr_detach.
Well, the problem is that the shirq->handlers list, i.e. the shirq
object itself may be in use
at the moment when xnintr_detach() is called. That said, the shirq
object as well as all the elements of shirq->handlers (those that have
been removed by xnintr_detach() from the list) must remain valid as
long as there is a isr handler for the given irq running (i.e.
To sum it up:
xnintr_shirq_spin() is for:
o "shirq" must be deleted only when the xnintr_irq_handler() for the
given irq has completed;
o even if there is no need to delete the "shirq" object (there are
other intr objects in the list) the xnintr_detach() must wait until
the handler gets completed, thas keeping intr->link valid.
Ok, maybe my explanation is a bit confusing but the direct analogy is
the way used in Linux, namely the synchroize_irq() call (take a look
at how it's used in free_irq()).
This is a kind of RCU. The element is removed from the list but it's
completely freed only when all the read clients are completed (in our
case, xnintr_irq_handler() and handle_IRQ_events() in Linux).
> Gilles Chanteperdrix.