On 07/07/2015 11:27 AM, Philippe Gerum wrote: > > - we want the target thread to relax from a safe and sane location. What > about the IRQ context which signals the mayday event preempting, e.g. > xnthread_relax() prologue, or any kernel code supposed to run in primary > mode only? We would have xnthread_relax() stacking over that context, > this wouldn't be pretty. Redirecting the target thread by fixing up the > interrupt frame gives such guarantee, by making sure that it will relax > on a regular user->kernel syscall transition asap, which is inherently safe. >
Actually, the code currently prevents mayday traps over non-user callers to skip foreign stack contexts such as Xenomai 2.x kthreads, so this bad scenario would not happen anyway. Besides, without such elimination the indirect call mechanism would not fix the unsafe preemption issue either. So, the remaining problem is with blackfin and its peculiar requirement about rescheduling, which is a barrier to a generic mayday handling. > I tested the patch on ARM. Enabling IPIPE_DEBUG_INTERNAL there reveals a > bug with the mayday handler now turning hw IRQs on, as a result of > relaxing over the low level IRQ trampoline, which makes some I-pipe call > in the irq_handler boilerplate code unhappy. The very same issue is > looming on x86, with an unprotected call to __ipipe_root_p from > __ipipe_handle_irq(). Disabling IRQs before leaving the mayday handler > is required at the very least. > Looking further, ARM is affected because it does not invoke __ipipe_call_mayday() for triggering the mayday trap, but still uses the open-coded method. This routine preserves the current hw state across the trap, which should make x86 safe in the end. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://xenomai.org/mailman/listinfo/xenomai
