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

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

[Jan Kiszka]

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).

I was playing with a different approach: Set a flag that mayday is
underway, let the interrupt context cause a fault (set ip to 0) and then
fix that up if we are in mayday mode. Seems to work fine (after fixing
some x86 ipipe issue) and would simplify the mayday logic apparently. So
I'm wondering why that approach wasn't chosen initially? IOW, what am I
missing?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Gilles Chanteperdrix]

On Wed, Dec 17, 2014 at 06:19:23PM +0100, 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.

Maybe we can restore it in xnarch_fixup_mayday, if nothing touches
it ?

-- 
					    Gilles.

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

[Philippe Gerum]

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).
> 
> I was playing with a different approach: Set a flag that mayday is
> underway, let the interrupt context cause a fault (set ip to 0) and then
> fix that up if we are in mayday mode. Seems to work fine (after fixing
> some x86 ipipe issue) and would simplify the mayday logic apparently. So
> I'm wondering why that approach wasn't chosen initially? IOW, what am I
> missing?
> 

The scheme had to work on MMU-less platforms as well, so jump <foobar>
seemed not a reasonable option.

-- 
Philippe.

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

[Jan Kiszka]

On 2014-12-17 18:17, Gilles Chanteperdrix wrote:
> On Wed, Dec 17, 2014 at 06:19:23PM +0100, 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.
> 
> Maybe we can restore it in xnarch_fixup_mayday, if nothing touches
> it ?

The problem is that cx is mangled again on preparing sysret - we are in
a syscall return path at that point, but we need an interrupt/exception
path in fact.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

On 2014-12-17 18:19, 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).
>>
>> I was playing with a different approach: Set a flag that mayday is
>> underway, let the interrupt context cause a fault (set ip to 0) and then
>> fix that up if we are in mayday mode. Seems to work fine (after fixing
>> some x86 ipipe issue) and would simplify the mayday logic apparently. So
>> I'm wondering why that approach wasn't chosen initially? IOW, what am I
>> missing?
>>
> 
> The scheme had to work on MMU-less platforms as well, so jump <foobar>
> seemed not a reasonable option.

True - but at least MMU/MPU-featured platforms could use this.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Gilles Chanteperdrix]

On Wed, Dec 17, 2014 at 06:36:47PM +0100, Jan Kiszka wrote:
> On 2014-12-17 18:17, Gilles Chanteperdrix wrote:
> > On Wed, Dec 17, 2014 at 06:19:23PM +0100, 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.
> > 
> > Maybe we can restore it in xnarch_fixup_mayday, if nothing touches
> > it ?
> 
> The problem is that cx is mangled again on preparing sysret - we are in
> a syscall return path at that point, but we need an interrupt/exception
> path in fact.

ARM had a similar issue with the register holding the syscall return
value, the fix was to return __xn_reg_rval(regs) in
the mayday syscall, is not this fix working for x86? How is cx
mangled exactly?

-- 
					    Gilles.

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

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

On 2014-12-17 18:45, Gilles Chanteperdrix wrote:
> On Wed, Dec 17, 2014 at 06:36:47PM +0100, Jan Kiszka wrote:
>> On 2014-12-17 18:17, Gilles Chanteperdrix wrote:
>>> On Wed, Dec 17, 2014 at 06:19:23PM +0100, 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.
>>>
>>> Maybe we can restore it in xnarch_fixup_mayday, if nothing touches
>>> it ?
>>
>> The problem is that cx is mangled again on preparing sysret - we are in
>> a syscall return path at that point, but we need an interrupt/exception
>> path in fact.
> 
> ARM had a similar issue with the register holding the syscall return
> value, the fix was to return __xn_reg_rval(regs) in
> the mayday syscall, is not this fix working for x86? How is cx
> mangled exactly?

rcx holds the ip of the context we call from / return to. So the return
path loads cx with the ip value saved in the register set on the stack.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Philippe Gerum]

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.

So this change would also break the Xenomai ABI (which is ok with x3,
but not an option for 2.6.4).

-- 
Philippe.

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

[Jan Kiszka]

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?

> 
> So this change would also break the Xenomai ABI (which is ok with x3,
> but not an option for 2.6.4).

Yes, 2.6 requires a compatible solution.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

On 2014-12-17 19:32, 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?

Can't imagine either: x86-64 does not take 64-bit syscalls via int80, no
matter if Linux or Xenomai.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Jan Kiszka]

On 2014-12-17 19:55, Philippe Gerum wrote:
> 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.

OK. Here is a hack that implements fault-based mayday support on x86:

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
index 544507c..d4300e7 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
@@ -40,6 +40,7 @@ struct xnarchtcb {
 		unsigned long ip;
 		unsigned long ax;
 		unsigned long sp;
+		bool pending;
 	} mayday;
 };
 
diff --git a/kernel/cobalt/arch/x86/mayday.c b/kernel/cobalt/arch/x86/mayday.c
index 4b986c9..6ed7fea 100644
--- a/kernel/cobalt/arch/x86/mayday.c
+++ b/kernel/cobalt/arch/x86/mayday.c
@@ -24,114 +24,18 @@
 #include <cobalt/uapi/syscall.h>
 #include <asm/ptrace.h>
 
-static void *mayday;
-#ifdef CONFIG_XENO_ARCH_SYS3264
-static void *mayday_compat;
-#endif
-
-static inline void setup_mayday32(void *page)
-{
-	/*
-	 * We want this code to appear at the top of the MAYDAY page:
-	 *
-	 *	b8 2b 02 00 0c		mov    $<mux_code>,%eax
-	 *      cd 80			int    $0x80
-	 *	0f 0b			ud2a
-	 *
-	 * We intentionally don't mess with EFLAGS here, so that we
-	 * don't have to save/restore it in handle/fixup code.
-	 */
-	static const struct __attribute__ ((__packed__)) {
-		struct __attribute__ ((__packed__)) {
-			u8 op;
-			u32 imm;
-		} mov_eax;
-		u16 syscall;
-		u16 bug;
-	} code = {
-		.mov_eax = {
-			.op = 0xb8,
-			.imm = __xn_syscode(sc_cobalt_mayday)
-		},
-		.syscall = 0x80cd,
-		.bug = 0x0b0f,
-	};
-
-	memcpy(page, &code, sizeof(code));
-
-	/* no cache flush required. */
-}
-
-static inline void setup_mayday64(void *page)
-{
-	/*
-	 * We want this code to appear at the top of the MAYDAY page:
-	 *
-	 *	b8 2b 02 00 0c		mov    $<mux_code>,%eax
-	 *	0f 05			syscall
-	 *	0f 0b			ud2a
-	 *
-	 * We intentionally don't mess with EFLAGS here, so that we
-	 * don't have to save/restore it in handle/fixup code.
-	 */
-	static const struct __attribute__ ((__packed__)) {
-		struct __attribute__ ((__packed__)) {
-			u8 op;
-			u32 imm;
-		} mov_eax;
-		u16 syscall;
-		u16 bug;
-	} code = {
-		.mov_eax = {
-			.op = 0xb8,
-			.imm = __xn_syscode(sc_cobalt_mayday)
-		},
-		.syscall = 0x050f,
-		.bug = 0x0b0f,
-	};
-
-	memcpy(page, &code, sizeof(code));
-
-	/* no cache flush required. */
-}
-
 int xnarch_init_mayday(void)
 {
-	mayday = vmalloc(PAGE_SIZE);
-	if (mayday == NULL)
-		return -ENOMEM;
-
-#ifdef CONFIG_X86_32
-	setup_mayday32(mayday);
-#else
-	setup_mayday64(mayday);
-#ifdef CONFIG_XENO_ARCH_SYS3264
-	mayday_compat = vmalloc(PAGE_SIZE);
-	if (mayday_compat == NULL) {
-		vfree(mayday);
-		return -ENOMEM;
-	}
-	setup_mayday32(mayday_compat);
-#endif
-#endif
 	return 0;
 }
 
 void xnarch_cleanup_mayday(void)
 {
-	vfree(mayday);
-#ifdef CONFIG_XENO_ARCH_SYS3264
-	vfree(mayday_compat);
-#endif
 }
 
 void *xnarch_get_mayday_page(void)
 {
-#if defined(CONFIG_X86_32) || !defined(CONFIG_XENO_ARCH_SYS3264)
-	return mayday;
-#else
-	return test_thread_flag(TIF_IA32) ? mayday_compat : mayday;
-#endif
+	return NULL;
 }
 
 void xnarch_handle_mayday(struct xnarchtcb *tcb, struct pt_regs *regs,
@@ -140,7 +44,8 @@ void xnarch_handle_mayday(struct xnarchtcb *tcb, struct pt_regs *regs,
 	tcb->mayday.sp = regs->sp;
 	tcb->mayday.ip = regs->ip;
 	tcb->mayday.ax = regs->ax;
-	regs->ip = tramp;
+	tcb->mayday.pending = true;
+	regs->ip = 0;
 }
 
 void xnarch_fixup_mayday(struct xnarchtcb *tcb, struct pt_regs *regs)
@@ -148,4 +53,5 @@ void xnarch_fixup_mayday(struct xnarchtcb *tcb, struct pt_regs *regs)
 	regs->ip = tcb->mayday.ip;
 	regs->ax = tcb->mayday.ax;
 	regs->sp = tcb->mayday.sp;
+	tcb->mayday.pending = false;
 }
diff --git a/kernel/cobalt/posix/process.c b/kernel/cobalt/posix/process.c
index 39f4e26..528836b 100644
--- a/kernel/cobalt/posix/process.c
+++ b/kernel/cobalt/posix/process.c
@@ -699,6 +699,12 @@ static inline int handle_exception(struct ipipe_trap_data *d)
 	if (xnthread_test_state(thread, XNROOT))
 		return 0;
 
+	if (xnthread_archtcb(thread)->mayday.pending) {
+		xnarch_fixup_mayday(xnthread_archtcb(thread), d->regs);
+		xnthread_relax(0, 0);
+		return 1;
+	}
+
 	trace_cobalt_thread_fault(thread, d);
 
 	if (xnarch_fault_fpu_p(d)) {
@@ -1256,10 +1262,13 @@ static inline unsigned long map_mayday_page(void)
 	int ret;
 
 	mayday_page = xnarch_get_mayday_page();
+	if (!mayday_page)
+		return 0UL;
+
 	ret = rtdm_mmap_to_user(NULL, mayday_page, PAGE_SIZE,
 				PROT_READ|PROT_EXEC, &u_addr, NULL, NULL);
 	if (ret)
-		return 0UL;
+		return -1UL;
 
 	return (unsigned long)u_addr;
 }
@@ -1278,7 +1287,7 @@ static int attach_process(struct cobalt_process *process)
 	cobalt_umm_set_name(&p->umm, "private heap[%d]", current->pid);
 
 	p->mayday_tramp = map_mayday_page();
-	if (p->mayday_tramp == 0) {
+	if (p->mayday_tramp == -1UL) {
 		printk(XENO_WARN
 		       "%s[%d] cannot map MAYDAY page\n",
 		       current->comm, current->pid);


The test case is in my for-forge queue, i.e. the ported sigdebug. I-pipe
bits are pushed to for-upstream/3.14 for reference. I had some troubles
with improper root irqs state when running the smokey test under gdb.
Not related to mayday, just a side effect of debugging the issue.
Should be fixed now.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

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

-- 
Philippe.

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

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

On 2015-02-12 17:36, Jan Kiszka wrote:
>> 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.

Will take longer - I need to convert all cobalt syscalls.

We have a sleeping bug there, though likely not seen in practice, with
syscalls returning values > INT_MAX (size_t...). The problem is that
handle_head/root_syscall only forwarded 32-bits so far.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

On 02/12/2015 06:02 PM, Jan Kiszka wrote:
> On 2015-02-12 17:36, Jan Kiszka wrote:
>>> 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.
> 
> Will take longer - I need to convert all cobalt syscalls.
> 
> We have a sleeping bug there, though likely not seen in practice, with
> syscalls returning values > INT_MAX (size_t...). The problem is that
> handle_head/root_syscall only forwarded 32-bits so far.
> 

You mean this, and all the implications of it?

diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c
index 6a9a02c..99b86a4 100644
--- a/kernel/cobalt/posix/syscall.c
+++ b/kernel/cobalt/posix/syscall.c
@@ -73,9 +73,9 @@
 /* Shorthand for oneway trap - does not return to call site. */
 #define __xn_exec_oneway    __xn_exec_norestart

-typedef int (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
-			      unsigned long arg3, unsigned long arg4,
-			      unsigned long arg5);
+typedef long (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
+			       unsigned long arg3, unsigned long arg4,
+			       unsigned long arg5);

 static void prepare_for_signal(struct task_struct *p,
 			       struct xnthread *thread,

-- 
Philippe.

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

[Jan Kiszka]

On 2015-02-12 18:07, Philippe Gerum wrote:
> On 02/12/2015 06:02 PM, Jan Kiszka wrote:
>> On 2015-02-12 17:36, Jan Kiszka wrote:
>>>> 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.
>>
>> Will take longer - I need to convert all cobalt syscalls.
>>
>> We have a sleeping bug there, though likely not seen in practice, with
>> syscalls returning values > INT_MAX (size_t...). The problem is that
>> handle_head/root_syscall only forwarded 32-bits so far.
>>
> 
> You mean this, and all the implications of it?
> 
> diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c
> index 6a9a02c..99b86a4 100644
> --- a/kernel/cobalt/posix/syscall.c
> +++ b/kernel/cobalt/posix/syscall.c
> @@ -73,9 +73,9 @@
>  /* Shorthand for oneway trap - does not return to call site. */
>  #define __xn_exec_oneway    __xn_exec_norestart
> 
> -typedef int (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
> -			      unsigned long arg3, unsigned long arg4,
> -			      unsigned long arg5);
> +typedef long (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
> +			       unsigned long arg3, unsigned long arg4,
> +			       unsigned long arg5);
> 
>  static void prepare_for_signal(struct task_struct *p,
>  			       struct xnthread *thread,
> 

Exactly.

Just done with the mechanics, crossing fingers it won't break things subtly.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

On 02/12/2015 06:16 PM, Jan Kiszka wrote:
> On 2015-02-12 18:07, Philippe Gerum wrote:
>> On 02/12/2015 06:02 PM, Jan Kiszka wrote:
>>> On 2015-02-12 17:36, Jan Kiszka wrote:
>>>>> 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.
>>>
>>> Will take longer - I need to convert all cobalt syscalls.
>>>
>>> We have a sleeping bug there, though likely not seen in practice, with
>>> syscalls returning values > INT_MAX (size_t...). The problem is that
>>> handle_head/root_syscall only forwarded 32-bits so far.
>>>
>>
>> You mean this, and all the implications of it?
>>
>> diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c
>> index 6a9a02c..99b86a4 100644
>> --- a/kernel/cobalt/posix/syscall.c
>> +++ b/kernel/cobalt/posix/syscall.c
>> @@ -73,9 +73,9 @@
>>  /* Shorthand for oneway trap - does not return to call site. */
>>  #define __xn_exec_oneway    __xn_exec_norestart
>>
>> -typedef int (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
>> -			      unsigned long arg3, unsigned long arg4,
>> -			      unsigned long arg5);
>> +typedef long (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
>> +			       unsigned long arg3, unsigned long arg4,
>> +			       unsigned long arg5);
>>
>>  static void prepare_for_signal(struct task_struct *p,
>>  			       struct xnthread *thread,
>>
> 
> Exactly.
> 
> Just done with the mechanics, crossing fingers it won't break things subtly.
> 

Ok. While we are at it, we should get rid of the syscall return type in
the COBALT_SYSCALL[_DECL] macro helpers, this is pointless.

-- 
Philippe.

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

[Jan Kiszka]

On 2015-02-12 18:18, Philippe Gerum wrote:
> On 02/12/2015 06:16 PM, Jan Kiszka wrote:
>> On 2015-02-12 18:07, Philippe Gerum wrote:
>>> On 02/12/2015 06:02 PM, Jan Kiszka wrote:
>>>> On 2015-02-12 17:36, Jan Kiszka wrote:
>>>>>> 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.
>>>>
>>>> Will take longer - I need to convert all cobalt syscalls.
>>>>
>>>> We have a sleeping bug there, though likely not seen in practice, with
>>>> syscalls returning values > INT_MAX (size_t...). The problem is that
>>>> handle_head/root_syscall only forwarded 32-bits so far.
>>>>
>>>
>>> You mean this, and all the implications of it?
>>>
>>> diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c
>>> index 6a9a02c..99b86a4 100644
>>> --- a/kernel/cobalt/posix/syscall.c
>>> +++ b/kernel/cobalt/posix/syscall.c
>>> @@ -73,9 +73,9 @@
>>>  /* Shorthand for oneway trap - does not return to call site. */
>>>  #define __xn_exec_oneway    __xn_exec_norestart
>>>
>>> -typedef int (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
>>> -			      unsigned long arg3, unsigned long arg4,
>>> -			      unsigned long arg5);
>>> +typedef long (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
>>> +			       unsigned long arg3, unsigned long arg4,
>>> +			       unsigned long arg5);
>>>
>>>  static void prepare_for_signal(struct task_struct *p,
>>>  			       struct xnthread *thread,
>>>
>>
>> Exactly.
>>
>> Just done with the mechanics, crossing fingers it won't break things subtly.
>>
> 
> Ok. While we are at it, we should get rid of the syscall return type in
> the COBALT_SYSCALL[_DECL] macro helpers, this is pointless.

Jep, that's what I did - hard-wired it to long.

First tests look good, just need to split things up into 3 or 4 patches now.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

On 2015-02-12 18:19, Jan Kiszka wrote:
> On 2015-02-12 18:18, Philippe Gerum wrote:
>> On 02/12/2015 06:16 PM, Jan Kiszka wrote:
>>> On 2015-02-12 18:07, Philippe Gerum wrote:
>>>> On 02/12/2015 06:02 PM, Jan Kiszka wrote:
>>>>> On 2015-02-12 17:36, Jan Kiszka wrote:
>>>>>>> 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.
>>>>>
>>>>> Will take longer - I need to convert all cobalt syscalls.
>>>>>
>>>>> We have a sleeping bug there, though likely not seen in practice, with
>>>>> syscalls returning values > INT_MAX (size_t...). The problem is that
>>>>> handle_head/root_syscall only forwarded 32-bits so far.
>>>>>
>>>>
>>>> You mean this, and all the implications of it?
>>>>
>>>> diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c
>>>> index 6a9a02c..99b86a4 100644
>>>> --- a/kernel/cobalt/posix/syscall.c
>>>> +++ b/kernel/cobalt/posix/syscall.c
>>>> @@ -73,9 +73,9 @@
>>>>  /* Shorthand for oneway trap - does not return to call site. */
>>>>  #define __xn_exec_oneway    __xn_exec_norestart
>>>>
>>>> -typedef int (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
>>>> -			      unsigned long arg3, unsigned long arg4,
>>>> -			      unsigned long arg5);
>>>> +typedef long (*cobalt_syshand)(unsigned long arg1, unsigned long arg2,
>>>> +			       unsigned long arg3, unsigned long arg4,
>>>> +			       unsigned long arg5);
>>>>
>>>>  static void prepare_for_signal(struct task_struct *p,
>>>>  			       struct xnthread *thread,
>>>>
>>>
>>> Exactly.
>>>
>>> Just done with the mechanics, crossing fingers it won't break things subtly.
>>>
>>
>> Ok. While we are at it, we should get rid of the syscall return type in
>> the COBALT_SYSCALL[_DECL] macro helpers, this is pointless.
> 
> Jep, that's what I did - hard-wired it to long.
> 
> First tests look good, just need to split things up into 3 or 4 patches now.

Done, see my for-forge branch.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

On 2015-02-12 18:45, Jan Kiszka wrote:
>>> Ok. While we are at it, we should get rid of the syscall return type in
>>> the COBALT_SYSCALL[_DECL] macro helpers, this is pointless.
>>
>> Jep, that's what I did - hard-wired it to long.
>>
>> First tests look good, just need to split things up into 3 or 4 patches now.
> 
> Done, see my for-forge branch.

BTW, we should also clean up the 32-bit syscall macros in the same way,
just to be consistent (on issue to fix over there). Can do when I ran
out of bugs (or need some distraction).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Philippe Gerum]

On 02/16/2015 06:37 PM, Jan Kiszka wrote:
> On 2015-02-12 18:45, Jan Kiszka wrote:
>>>> Ok. While we are at it, we should get rid of the syscall return type in
>>>> the COBALT_SYSCALL[_DECL] macro helpers, this is pointless.
>>>
>>> Jep, that's what I did - hard-wired it to long.
>>>
>>> First tests look good, just need to split things up into 3 or 4 patches now.
>>
>> Done, see my for-forge branch.
> 
> BTW, we should also clean up the 32-bit syscall macros in the same way,
> just to be consistent (on issue to fix over there). Can do when I ran
> out of bugs (or need some distraction).
> 

Ack.


-- 
Philippe.

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

[Philippe Gerum]

On 02/16/2015 06:43 PM, Philippe Gerum wrote:
> On 02/16/2015 06:37 PM, Jan Kiszka wrote:
>> On 2015-02-12 18:45, Jan Kiszka wrote:
>>>>> Ok. While we are at it, we should get rid of the syscall return type in
>>>>> the COBALT_SYSCALL[_DECL] macro helpers, this is pointless.
>>>>
>>>> Jep, that's what I did - hard-wired it to long.
>>>>
>>>> First tests look good, just need to split things up into 3 or 4 patches now.
>>>
>>> Done, see my for-forge branch.
>>
>> BTW, we should also clean up the 32-bit syscall macros in the same way,
>> just to be consistent (on issue to fix over there). Can do when I ran
>> out of bugs (or need some distraction).
>>
> 
> Ack.
> 
> 

Don't bother with this, I'm doing the conversion.

-- 
Philippe.