Re: [REQUEST] eliminate the rthal_critical_enter/exit() from rthal_irq_request()

Dmitry Adamushko wrote:
> Hi,
>
> I haven't had access to my laptop during this week so the patches
> follow only now.

Merged, thanks.

> Yet another issue remains that may lead to a deadlock under some circumstances:
>
> - rt_intr_delete() calls xnintr_detach() while holding the "nklock".
>
> - xnintr_detach() (with CONFIG_SMP) spins in xnintr_shirq_spin()
> when a corresponding ISR is currently running.
>
> - now this ISR calls any function that uses "nklock" (everything make
> use of it) ... Bum!
>
> I first thought about moving xnintr_detach() out of the locked section
> in rt_intr_delete() but it somewhat breaks interface consistency ---
> e.g. xeno_mark_delete() is called before the object is completely
> destroyed.

That's not a problem, the deletion marker will never be anything else 
than a pure magic word stored in some object's descriptor, so we could 
indeed first mark the object as deleted, then release the lock before 
proceeding to the actual deletion.

> Another approach would be to introduce a service like
> xnintr_synchronize() and enfource the upper interfaces (e.g. skins) to
> make use of it in their _delete() methods.

That would be useful too for solving the "concurrent ISR while deleting 
issue", but would not enforce single deletion in the SMP case, I guess.

> The problem here is that the xnintr_shirq - interface is not complete
> and safe without xnintr_shirq_spin() on detaching step and it becomes
> somewhat blured with the enforcement like "on SMP systems one should
> always call xnintr_synchronize() right after calling xnintr_detach()".
>
> So I'm still thinking how to fix it better...
>
>
> --
> Best regards,
> Dmitry Adamushko


--

Philippe.