Re: [Xenomai] Mayday issues again

[Philippe Gerum <rpm@xenomai.org>]

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.