On 07/07/2015 03:01 PM, Jan Kiszka wrote: > On 2015-07-07 14:53, Philippe Gerum wrote: >> 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. > > Yes, that is the assumption I was building upon. And, BTW, faults do > happen over kernel contexts as well and cause relaxing then: > copy_to/from_user. So that has to work already. >
copy_* are specific: they should never happen over an unsafe or atomic context by design. That context can be considered as an extension of the plain userland context in our case. > But Blackfin was my concern as well, and you confirmed it. But how does > Linux address the need for rescheduling on IRQ return - which should be > similar to what we need for relaxing? The kernel schedules a delayed call from the IRQ/trap epilogue, which will run at the lowest priority from vector EVT15, which guarantees the absence of nesting, since other core events such as IRQs have higher priority (e.g. schedule_and_signal_from_int, mach-common/entry.S). > >> >>> 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. >> > > ARM is not yet properly tested, just a quick smoke test. I will > eventually look into this. > > Another reason I'm trying to overcome the mayday trampoline is that it > prevents properly synchronized stopping and resuming of RT threads for > debugging purposes. I'm trying to address this requirement with a > userspace trap/irq return notifier, similar to what Linux has > (implemented on x86-only so far) but capable of hardening the context > before returning. > > Jan > -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://xenomai.org/mailman/listinfo/xenomai
