Re: [Xenomai] Mayday mechanism broken on x86-64 - simpler approach feasible?

[Philippe Gerum <rpm@xenomai.org>]

On 02/12/2015 05:36 PM, Jan Kiszka wrote:
> On 2015-02-03 16:29, Philippe Gerum wrote:
>> On 12/17/2014 07:55 PM, Philippe Gerum wrote:
>>> On 12/17/2014 07:32 PM, Jan Kiszka wrote:
>>>> On 2014-12-17 19:28, Philippe Gerum wrote:
>>>>> On 12/17/2014 06:46 PM, Jan Kiszka wrote:
>>>>>> On 2014-12-17 18:52, Philippe Gerum wrote:
>>>>>>> On 12/17/2014 05:57 PM, Jan Kiszka wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> while porting the sigdebug test case to forge I noticed occasional
>>>>>>>> crashes of the test after it received a watchdog signal. It turned out
>>>>>>>> that the problem is in the way mayday works on x86-64:
>>>>>>>>
>>>>>>>> 1. sp/ip/ax of interrupted thread is saved
>>>>>>>> 2. ip is set to mayday page
>>>>>>>> 3. mayday page executes the mayday syscall via the syscall instruction
>>>>>>>> 4. the syscall restores state on original state on return
>>>>>>>>
>>>>>>>> That that's the theory. Unfortunately the syscall instructions
>>>>>>>> overwrites the cx register with the caller's instruction pointer. We
>>>>>>>> could save it but there is no way to restore it on syscall return
>>>>>>>> without significant changes to the Linux code in entry_64.S.
>>>>>>>>
>>>>>>>> x86-32 is fine as it uses the int80 path which does a full state
>>>>>>>> recovery - but that is not available for 64-bit (only via ia32 compat,
>>>>>>>> but that can be turned off).
>>>>>>>>
>>>>>>>
>>>>>>> The legacy system_call vector is available unconditionally to x86_64.
>>>>>>> Xenomai 3 is actually calling int80 unconditionally on mayday traps for
>>>>>>> these reasons, i.e. always available and not suffering the long-mode
>>>>>>> syscall registers issue.
>>>>>>
>>>>>> Only when setting CONFIG_IA32_EMULATION. That is typcially the case, but
>>>>>> not necessarily.
>>>>>>
>>>>>
>>>>> I mean: the "safe" Xenomai syscall form (the one that binds a process to
>>>>> the real-time core in dual kernel mode) depends on this. Disabling int80
>>>>> is not an option in the current Xenomai implementation, mayday feature
>>>>> put aside.
>>>>
>>>> Huh? Things worked fine here on X3 when trying out the effect of
>>>> disabling IA32 emulation. Or do you mean 2.6?
>>>>
>>>
>>> I meant to tell crap: x86_64 implies vsyscall available, so there is no
>>> "safe" binding prologue there. Only x86_32 has this, so that legacy
>>> non-NPTL libc which do not support vsyscall work. So back to the initial
>>> discussion.
>>>
>>
>> As I mentioned earlier, I'd rather fix the MAYDAY implementation for
>> x86_64 instead of forking the implementation between MMU-enabled and
>> MMU-less architectures, also affecting powerpc, arm and x86_32 in the
>> same move. Fortunately, the current implementation allows very specific
>> tweaks to be applied on a per-architecture basis. This one fixes the
>> issue for Cobalt on x86_64, and could be easily backported to 2.6.x:
>>
>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=6db20901963d634b9786467c711c2ba526db48a2
> 
> Looks almost good - except for the detail that some bits of the
> instruction pointer are lost on return from the syscall (int vs. long
> return type). Patches in the making.
> 

There could be another issue with %rsp. I'm checking this.


-- 
Philippe.