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 > all > > 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: > > CPU1 > 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 > > CPU2 > 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. xnintr_irq_handler() ). 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. > -- Best regards, Dmitry Adamushko
