[Xenomai-help] rt_task_shadow returns always -EFAULT

[Xenomai-help] rt_task_shadow returns always -EFAULT

[Petr Cervenka]

Hello,
the xenomai native function rt_task_shadow(...) always returns -EFAULT for me. Only happens in xenomai-2.5-rc2.

Same behaviour was also in 2.5-rc1, see note in my older post:
https://mail.gna.org/public/xenomai-help/2009-05/msg00024.html

Example code, in the end of this post:
https://mail.gna.org/public/xenomai-help/2009-05/msg00038.html

My configuration:
Athlon 64 X2 4600+
Kubuntu 7.10
linux-2.6.29.5 (also tried 2.6.30.1)
xenomai-2.5.-rc2

Best regards

Petr Cervenka

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Philippe Gerum]

On Thu, 2009-07-16 at 15:15 +0200, Petr Cervenka wrote:
> Hello,
> the xenomai native function rt_task_shadow(...) always returns -EFAULT for me. Only happens in xenomai-2.5-rc2.
> 
> Same behaviour was also in 2.5-rc1, see note in my older post:
> https://mail.gna.org/public/xenomai-help/2009-05/msg00024.html
> 
> Example code, in the end of this post:
> https://mail.gna.org/public/xenomai-help/2009-05/msg00038.html
> 
> My configuration:
> Athlon 64 X2 4600+
> Kubuntu 7.10
> linux-2.6.29.5 (also tried 2.6.30.1)
> xenomai-2.5.-rc2

Does this still break when the name is passed as illustrated below?

--- petr.c~	2009-07-16 15:50:46.000000000 +0200
+++ petr.c	2009-07-16 16:28:31.000000000 +0200
@@ -14,11 +14,12 @@
     RT_EVENT event;
     unsigned long mask;
     RTIME start, end;
+    char name[32];
     int res;
 
     mlockall(MCL_CURRENT | MCL_FUTURE);
 
-    res = rt_task_shadow(&mainTask, "main_task", MY_PRIORITY, 0);
+    res = rt_task_shadow(&mainTask, strcpy(name, "main_task"), MY_PRIORITY, 0);
     if (res < 0) {
         printf("rt_task_shadow(): %d (%s)\n", res, strerror(-res));
     }

> 
> Best regards
> 
> Petr Cervenka
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Petr Cervenka]

>On Thu, 2009-07-16 at 15:15 +0200, Petr Cervenka wrote:
>> Hello,
>> the xenomai native function rt_task_shadow(...) always returns -EFAULT for me. Only happens in xenomai-2.5-rc2.
>> 
>> Same behaviour was also in 2.5-rc1, see note in my older post:
>> https://mail.gna.org/public/xenomai-help/2009-05/msg00024.html
>> 
>> Example code, in the end of this post:
>> https://mail.gna.org/public/xenomai-help/2009-05/msg00038.html
>> 
>> My configuration:
>> Athlon 64 X2 4600+
>> Kubuntu 7.10
>> linux-2.6.29.5 (also tried 2.6.30.1)
>> xenomai-2.5.-rc2
>
>Does this still break when the name is passed as illustrated below?
>

No, it doesn't help.

I also tried the xenomai rtprint example -> same behavior. The rt_task_shadow() returns -EFAULT and any following rt_task_sleep() in that task returns -1. The other task works fine.
I will do some deeper examination of rt_task_shadow() code.
If you have any advices, what to send or what to try, i would like to hear it.

>--- petr.c~	2009-07-16 15:50:46.000000000 +0200
>+++ petr.c	2009-07-16 16:28:31.000000000 +0200
>@@ -14,11 +14,12 @@
>     RT_EVENT event;
>     unsigned long mask;
>     RTIME start, end;
>+    char name[32];
>     int res;
> 
>     mlockall(MCL_CURRENT | MCL_FUTURE);
> 
>-    res = rt_task_shadow(&mainTask, "main_task", MY_PRIORITY, 0);
>+    res = rt_task_shadow(&mainTask, strcpy(name, "main_task"), MY_PRIORITY, 0);
>     if (res < 0) {
>         printf("rt_task_shadow(): %d (%s)n", res, strerror(-res));
>     }
>
>> 
>> Best regards
>> 
>> Petr Cervenka
>> 
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>-- 
>Philippe.
>
>
Petr

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Philippe Gerum]

On Fri, 2009-07-17 at 13:17 +0200, Petr Cervenka wrote:
> >On Thu, 2009-07-16 at 15:15 +0200, Petr Cervenka wrote:
> >> Hello,
> >> the xenomai native function rt_task_shadow(...) always returns -EFAULT for me. Only happens in xenomai-2.5-rc2.
> >> 
> >> Same behaviour was also in 2.5-rc1, see note in my older post:
> >> https://mail.gna.org/public/xenomai-help/2009-05/msg00024.html
> >> 
> >> Example code, in the end of this post:
> >> https://mail.gna.org/public/xenomai-help/2009-05/msg00038.html
> >> 
> >> My configuration:
> >> Athlon 64 X2 4600+
> >> Kubuntu 7.10
> >> linux-2.6.29.5 (also tried 2.6.30.1)
> >> xenomai-2.5.-rc2
> >
> >Does this still break when the name is passed as illustrated below?
> >
> 
> No, it doesn't help.
> 
> I also tried the xenomai rtprint example -> same behavior. The rt_task_shadow() returns -EFAULT and any following rt_task_sleep() in that task returns -1. The other task works fine.
> I will do some deeper examination of rt_task_shadow() code.
> If you have any advices, what to send or what to try, i would like to hear it.
> 

Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
identify which spot returns -EFAULT. I can't reproduce this issue on a
ppc target; I may try over x86 later, but this would speed up things if
you could spot the failing test before I'm able to switch to this.

> >--- petr.c~	2009-07-16 15:50:46.000000000 +0200
> >+++ petr.c	2009-07-16 16:28:31.000000000 +0200
> >@@ -14,11 +14,12 @@
> >     RT_EVENT event;
> >     unsigned long mask;
> >     RTIME start, end;
> >+    char name[32];
> >     int res;
> > 
> >     mlockall(MCL_CURRENT | MCL_FUTURE);
> > 
> >-    res = rt_task_shadow(&mainTask, "main_task", MY_PRIORITY, 0);
> >+    res = rt_task_shadow(&mainTask, strcpy(name, "main_task"), MY_PRIORITY, 0);
> >     if (res < 0) {
> >         printf("rt_task_shadow(): %d (%s)n", res, strerror(-res));
> >     }
> >
> >> 
> >> Best regards
> >> 
> >> Petr Cervenka
> >> 
> >> _______________________________________________
> >> Xenomai-help mailing list
> >> Xenomai-help@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-help
> >-- 
> >Philippe.
> >
> >
> Petr
-- 
Philippe.

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Petr Cervenka]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

>
>On Fri, 2009-07-17 at 13:17 +0200, Petr Cervenka wrote:
>> >On Thu, 2009-07-16 at 15:15 +0200, Petr Cervenka wrote:
>> >> Hello,
>> >> the xenomai native function rt_task_shadow(...) always returns -EFAULT for me. Only happens in xenomai-2.5-rc2.
>> >> 
>> >> Same behaviour was also in 2.5-rc1, see note in my older post:
>> >> https://mail.gna.org/public/xenomai-help/2009-05/msg00024.html
>> >> 
>> >> Example code, in the end of this post:
>> >> https://mail.gna.org/public/xenomai-help/2009-05/msg00038.html
>> >> 
>> >> My configuration:
>> >> Athlon 64 X2 4600+
>> >> Kubuntu 7.10
>> >> linux-2.6.29.5 (also tried 2.6.30.1)
>> >> xenomai-2.5.-rc2
>> >
>> >Does this still break when the name is passed as illustrated below?
>> >
>> 
>> No, it doesn't help.
>> 
>> I also tried the xenomai rtprint example -> same behavior. The rt_task_shadow() returns -EFAULT and any following rt_task_sleep() in that task returns -1. The other task works fine.
>> I will do some deeper examination of rt_task_shadow() code.
>> If you have any advices, what to send or what to try, i would like to hear it.
>> 
>
>Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>identify which spot returns -EFAULT. I can't reproduce this issue on a
>ppc target; I may try over x86 later, but this would speed up things if
>you could spot the failing test before I'm able to switch to this.
>

Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
But most attempts to confirm, that the value is returned by line:
	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
				NULL);
where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
--- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
+++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
@@ -241,6 +241,7 @@
        pthread_setspecific(__native_tskey, NULL);
        free(self);
 #endif /* !HAVE___THREAD */
+       rt_task_set_mode(0, 0, NULL);
        return err;
 }

objdumps of original and changed rt_task_shadow() is in attachment

I will continue in research, but I'm really not good in dissasembling nor the register knowledge.

Petr

[-- Attachment #2: rt_task_shadow_1.txt --]
[-- Type: text/plain, Size: 3146 bytes --]

00000000000006d0 <rt_task_shadow>:
 6d0:   48 89 5c 24 d8          mov    %rbx,-0x28(%rsp)
 6d5:   48 89 6c 24 e0          mov    %rbp,-0x20(%rsp)
 6da:   48 89 fd                mov    %rdi,%rbp
 6dd:   4c 89 64 24 e8          mov    %r12,-0x18(%rsp)
 6e2:   4c 89 6c 24 f0          mov    %r13,-0x10(%rsp)
 6e7:   49 89 f4                mov    %rsi,%r12
 6ea:   4c 89 74 24 f8          mov    %r14,-0x8(%rsp)
 6ef:   48 83 ec 68             sub    $0x68,%rsp
 6f3:   48 85 ff                test   %rdi,%rdi
 6f6:   48 8d 44 24 30          lea    0x30(%rsp),%rax
 6fb:   bf 01 00 00 00          mov    $0x1,%edi
 700:   41 89 d5                mov    %edx,%r13d
 703:   41 89 ce                mov    %ecx,%r14d
 706:   48 0f 44 e8             cmove  %rax,%rbp
 70a:   31 f6                   xor    %esi,%esi
 70c:   e8 00 00 00 00          callq  711 <rt_task_shadow+0x41>
 711:   be 00 00 00 00          mov    $0x0,%esi
 716:   bf 00 00 00 00          mov    $0x0,%edi
 71b:   e8 00 00 00 00          callq  720 <rt_task_shadow+0x50>
 720:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 727 <rt_task_shadow+0x57>
 727:   64 48 03 04 25 00 00    add    %fs:0x0,%rax
 72e:   00 00
 730:   8b 1d 00 00 00 00       mov    0x0(%rip),%ebx        # 736 <rt_task_shadow+0x66>
 736:   48 89 44 24 28          mov    %rax,0x28(%rsp)
 73b:   81 cb 2b 02 00 00       or     $0x22b,%ebx
 741:   e8 00 00 00 00          callq  746 <rt_task_shadow+0x76>
 746:   48 89 44 24 20          mov    %rax,0x20(%rsp)
 74b:   49 63 c6                movslq %r14d,%rax
 74e:   4c 89 64 24 08          mov    %r12,0x8(%rsp)
 753:   48 89 44 24 18          mov    %rax,0x18(%rsp)
 758:   49 63 c5                movslq %r13d,%rax
 75b:   48 89 2c 24             mov    %rbp,(%rsp)
 75f:   48 89 44 24 10          mov    %rax,0x10(%rsp)
 764:   89 d8                   mov    %ebx,%eax
 766:   0f 05                   syscall
 768:   85 c0                   test   %eax,%eax
 76a:   49 89 c4                mov    %rax,%r12
 76d:   89 c3                   mov    %eax,%ebx
 76f:   75 31                   jne    7a2 <rt_task_shadow+0xd2>
 771:   48 8b 55 00             mov    0x0(%rbp),%rdx
 775:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 77c <rt_task_shadow+0xac>
 77c:   64 48 89 10             mov    %rdx,%fs:(%rax)
 780:   48 8b 55 08             mov    0x8(%rbp),%rdx
 784:   64 48 89 50 08          mov    %rdx,%fs:0x8(%rax)
 789:   e8 00 00 00 00          callq  78e <rt_task_shadow+0xbe>
 78e:   41 81 e6 00 00 02 00    and    $0x20000,%r14d
 795:   0f 44 1d 00 00 00 00    cmove  0x0(%rip),%ebx        # 79c <rt_task_shadow+0xcc>
 79c:   89 1d 00 00 00 00       mov    %ebx,0x0(%rip)        # 7a2 <rt_task_shadow+0xd2>
 7a2:   44 89 e0                mov    %r12d,%eax
 7a5:   48 8b 5c 24 40          mov    0x40(%rsp),%rbx
 7aa:   48 8b 6c 24 48          mov    0x48(%rsp),%rbp
 7af:   4c 8b 64 24 50          mov    0x50(%rsp),%r12
 7b4:   4c 8b 6c 24 58          mov    0x58(%rsp),%r13
 7b9:   4c 8b 74 24 60          mov    0x60(%rsp),%r14
 7be:   48 83 c4 68             add    $0x68,%rsp
 7c2:   c3                      retq

[-- Attachment #3: rt_task_shadow_2.txt --]
[-- Type: text/plain, Size: 3304 bytes --]

00000000000006d0 <rt_task_shadow>:
 6d0:   48 89 5c 24 e0          mov    %rbx,-0x20(%rsp)
 6d5:   48 89 6c 24 e8          mov    %rbp,-0x18(%rsp)
 6da:   48 89 fd                mov    %rdi,%rbp
 6dd:   4c 89 64 24 f0          mov    %r12,-0x10(%rsp)
 6e2:   4c 89 6c 24 f8          mov    %r13,-0x8(%rsp)
 6e7:   48 83 ec 68             sub    $0x68,%rsp
 6eb:   48 8d 44 24 30          lea    0x30(%rsp),%rax
 6f0:   48 85 ff                test   %rdi,%rdi
 6f3:   48 89 f3                mov    %rsi,%rbx
 6f6:   bf 01 00 00 00          mov    $0x1,%edi
 6fb:   41 89 d4                mov    %edx,%r12d
 6fe:   41 89 cd                mov    %ecx,%r13d
 701:   48 0f 44 e8             cmove  %rax,%rbp
 705:   31 f6                   xor    %esi,%esi
 707:   e8 00 00 00 00          callq  70c <rt_task_shadow+0x3c>
 70c:   be 00 00 00 00          mov    $0x0,%esi
 711:   bf 00 00 00 00          mov    $0x0,%edi
 716:   e8 00 00 00 00          callq  71b <rt_task_shadow+0x4b>
 71b:   49 63 c4                movslq %r12d,%rax
 71e:   48 89 2c 24             mov    %rbp,(%rsp)
 722:   48 89 5c 24 08          mov    %rbx,0x8(%rsp)
 727:   48 89 44 24 10          mov    %rax,0x10(%rsp)
 72c:   49 63 c5                movslq %r13d,%rax
 72f:   48 89 44 24 18          mov    %rax,0x18(%rsp)
 734:   e8 00 00 00 00          callq  739 <rt_task_shadow+0x69>
 739:   48 89 44 24 20          mov    %rax,0x20(%rsp)
 73e:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 745 <rt_task_shadow+0x75>
 745:   48 89 e7                mov    %rsp,%rdi
 748:   64 48 03 04 25 00 00    add    %fs:0x0,%rax
 74f:   00 00
 751:   31 f6                   xor    %esi,%esi
 753:   48 89 44 24 28          mov    %rax,0x28(%rsp)
 758:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 75e <rt_task_shadow+0x8e>
 75e:   0d 2b 02 00 00          or     $0x22b,%eax
 763:   0f 05                   syscall
 765:   85 c0                   test   %eax,%eax
 767:   89 c3                   mov    %eax,%ebx
 769:   74 26                   je     791 <rt_task_shadow+0xc1>
 76b:   31 d2                   xor    %edx,%edx
 76d:   31 f6                   xor    %esi,%esi
 76f:   31 ff                   xor    %edi,%edi
 771:   e8 00 00 00 00          callq  776 <rt_task_shadow+0xa6>
 776:   89 d8                   mov    %ebx,%eax
 778:   48 8b 6c 24 50          mov    0x50(%rsp),%rbp
 77d:   48 8b 5c 24 48          mov    0x48(%rsp),%rbx
 782:   4c 8b 64 24 58          mov    0x58(%rsp),%r12
 787:   4c 8b 6c 24 60          mov    0x60(%rsp),%r13
 78c:   48 83 c4 68             add    $0x68,%rsp
 790:   c3                      retq
 791:   48 8b 55 00             mov    0x0(%rbp),%rdx
 795:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 79c <rt_task_shadow+0xcc>
 79c:   64 48 89 10             mov    %rdx,%fs:(%rax)
 7a0:   48 8b 55 08             mov    0x8(%rbp),%rdx
 7a4:   64 48 89 50 08          mov    %rdx,%fs:0x8(%rax)
 7a9:   e8 00 00 00 00          callq  7ae <rt_task_shadow+0xde>
 7ae:   41 81 e5 00 00 02 00    and    $0x20000,%r13d
 7b5:   74 bf                   je     776 <rt_task_shadow+0xa6>
 7b7:   c7 05 00 00 00 00 00    movl   $0x0,0x0(%rip)        # 7c1 <rt_task_shadow+0xf1>
 7be:   00 00 00
 7c1:   eb b3                   jmp    776 <rt_task_shadow+0xa6>

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Philippe Gerum]

On Fri, 2009-07-17 at 15:32 +0200, Petr Cervenka wrote:
> >
> >On Fri, 2009-07-17 at 13:17 +0200, Petr Cervenka wrote:
> >> >On Thu, 2009-07-16 at 15:15 +0200, Petr Cervenka wrote:
> >> >> Hello,
> >> >> the xenomai native function rt_task_shadow(...) always returns -EFAULT for me. Only happens in xenomai-2.5-rc2.
> >> >> 
> >> >> Same behaviour was also in 2.5-rc1, see note in my older post:
> >> >> https://mail.gna.org/public/xenomai-help/2009-05/msg00024.html
> >> >> 
> >> >> Example code, in the end of this post:
> >> >> https://mail.gna.org/public/xenomai-help/2009-05/msg00038.html
> >> >> 
> >> >> My configuration:
> >> >> Athlon 64 X2 4600+
> >> >> Kubuntu 7.10
> >> >> linux-2.6.29.5 (also tried 2.6.30.1)
> >> >> xenomai-2.5.-rc2
> >> >
> >> >Does this still break when the name is passed as illustrated below?
> >> >
> >> 
> >> No, it doesn't help.
> >> 
> >> I also tried the xenomai rtprint example -> same behavior. The rt_task_shadow() returns -EFAULT and any following rt_task_sleep() in that task returns -1. The other task works fine.
> >> I will do some deeper examination of rt_task_shadow() code.
> >> If you have any advices, what to send or what to try, i would like to hear it.
> >> 
> >
> >Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
> >identify which spot returns -EFAULT. I can't reproduce this issue on a
> >ppc target; I may try over x86 later, but this would speed up things if
> >you could spot the failing test before I'm able to switch to this.
> >
> 
> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
> But most attempts to confirm, that the value is returned by line:
> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
> 				NULL);

This branches to __rt_task_create in kernel space.

> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
> @@ -241,6 +241,7 @@
>         pthread_setspecific(__native_tskey, NULL);
>         free(self);
>  #endif /* !HAVE___THREAD */
> +       rt_task_set_mode(0, 0, NULL);
>         return err;
>  }
> 
> objdumps of original and changed rt_task_shadow() is in attachment
> 
> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
> 

Try rebuilding the user-space libs passing --without-__thread to the
configure script.

> Petr
-- 
Philippe.

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Petr Cervenka]

>> >
>> >Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>> >identify which spot returns -EFAULT. I can't reproduce this issue on a
>> >ppc target; I may try over x86 later, but this would speed up things if
>> >you could spot the failing test before I'm able to switch to this.
>> >
>> 
>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>> But most attempts to confirm, that the value is returned by line:
>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>> 				NULL);
>
>This branches to __rt_task_create in kernel space.
>

The bulk variable is totally wrong in kernel space:
for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
It fails on following line (syscall.c:aprox. 193):
	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {

>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>> @@ -241,6 +241,7 @@
>>         pthread_setspecific(__native_tskey, NULL);
>>         free(self);
>>  #endif /* !HAVE___THREAD */
>> +       rt_task_set_mode(0, 0, NULL);
>>         return err;
>>  }
>> 
>> objdumps of original and changed rt_task_shadow() is in attachment
>> 
>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>> 
>
>Try rebuilding the user-space libs passing --without-__thread to the
>configure script.
>

After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
Do you already know, where the problem is? What does the "--without-__thread" argument mean?

Petr

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

Petr Cervenka wrote:
>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>> identify which spot returns -EFAULT. I can't reproduce this issue on a
>>>> ppc target; I may try over x86 later, but this would speed up things if
>>>> you could spot the failing test before I'm able to switch to this.
>>>>
>>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>>> But most attempts to confirm, that the value is returned by line:
>>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>>> 				NULL);
>> This branches to __rt_task_create in kernel space.
>>
> 
> The bulk variable is totally wrong in kernel space:
> for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
> It fails on following line (syscall.c:aprox. 193):
> 	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {
> 
>>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>>> @@ -241,6 +241,7 @@
>>>         pthread_setspecific(__native_tskey, NULL);
>>>         free(self);
>>>  #endif /* !HAVE___THREAD */
>>> +       rt_task_set_mode(0, 0, NULL);
>>>         return err;
>>>  }
>>>
>>> objdumps of original and changed rt_task_shadow() is in attachment
>>>
>>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>>>
>> Try rebuilding the user-space libs passing --without-__thread to the
>> configure script.
>>
> 
> After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
> Do you already know, where the problem is? What does the "--without-__thread" argument mean?

It's reproducible, will try to understand it. It's either a compiler bug
(your kubuntu version is fairly old and also unsupported due to security
flaws), or we actually still have a problems around TLS variables
(Thread Local Storage, that's what --without-__thread disables).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Petr Cervenka wrote:
>>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>>> identify which spot returns -EFAULT. I can't reproduce this issue on a
>>>>> ppc target; I may try over x86 later, but this would speed up things if
>>>>> you could spot the failing test before I'm able to switch to this.
>>>>>
>>>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>>>> But most attempts to confirm, that the value is returned by line:
>>>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>>>> 				NULL);
>>> This branches to __rt_task_create in kernel space.
>>>
>> The bulk variable is totally wrong in kernel space:
>> for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
>> It fails on following line (syscall.c:aprox. 193):
>> 	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {
>>
>>>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>>>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>>>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>>>> @@ -241,6 +241,7 @@
>>>>         pthread_setspecific(__native_tskey, NULL);
>>>>         free(self);
>>>>  #endif /* !HAVE___THREAD */
>>>> +       rt_task_set_mode(0, 0, NULL);
>>>>         return err;
>>>>  }
>>>>
>>>> objdumps of original and changed rt_task_shadow() is in attachment
>>>>
>>>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>>>>
>>> Try rebuilding the user-space libs passing --without-__thread to the
>>> configure script.
>>>
>> After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
>> Do you already know, where the problem is? What does the "--without-__thread" argument mean?
> 
> It's reproducible, will try to understand it. It's either a compiler bug

That would be the second compiler bug with __thread (we have a bug on
arm). If we add this to the fact that supporting __thread clutters the
code with many #ifdefs, and does not improve performances on other
platforms than x86 where so many cycles are executed by nanosecond that
it does not matter that much, I'd say let's get rid of __thread.

Besides, it really looks like C++ syntactic sugar where the compiler
makes things behind my back when I use a seemingly simple syntax, it
does not conform with what I would expect from a C compiler.

-- 
					    Gilles.

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Petr Cervenka wrote:
>>>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>>>> identify which spot returns -EFAULT. I can't reproduce this issue on a
>>>>>> ppc target; I may try over x86 later, but this would speed up things if
>>>>>> you could spot the failing test before I'm able to switch to this.
>>>>>>
>>>>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>>>>> But most attempts to confirm, that the value is returned by line:
>>>>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>>>>> 				NULL);
>>>> This branches to __rt_task_create in kernel space.
>>>>
>>> The bulk variable is totally wrong in kernel space:
>>> for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
>>> It fails on following line (syscall.c:aprox. 193):
>>> 	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {
>>>
>>>>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>>>>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>>>>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>>>>> @@ -241,6 +241,7 @@
>>>>>         pthread_setspecific(__native_tskey, NULL);
>>>>>         free(self);
>>>>>  #endif /* !HAVE___THREAD */
>>>>> +       rt_task_set_mode(0, 0, NULL);
>>>>>         return err;
>>>>>  }
>>>>>
>>>>> objdumps of original and changed rt_task_shadow() is in attachment
>>>>>
>>>>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>>>>>
>>>> Try rebuilding the user-space libs passing --without-__thread to the
>>>> configure script.
>>>>
>>> After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
>>> Do you already know, where the problem is? What does the "--without-__thread" argument mean?
>> It's reproducible, will try to understand it. It's either a compiler bug
> 
> That would be the second compiler bug with __thread (we have a bug on
> arm). If we add this to the fact that supporting __thread clutters the
> code with many #ifdefs, and does not improve performances on other
> platforms than x86 where so many cycles are executed by nanosecond that
> it does not matter that much, I'd say let's get rid of __thread.
> 
> Besides, it really looks like C++ syntactic sugar where the compiler
> makes things behind my back when I use a seemingly simple syntax, it
> does not conform with what I would expect from a C compiler.
> 

TLS was just the catalyst. The x86_64 syscall interface is defined in a
too fragile way. As Petr already noticed, the core of the problem is
that the syscall argument &bulk does not reach the kernel. And if you
look at the disassembly kubuntu's gcc-4.3.1 generates, it's obvious why:
rdi is not initialized at all with &bulk. For some reason, the compiler
thinks it could leave this out or rdi would already contain the correct
address.

However, I successfully applied the pattern Xen hypercalls use ("+r"
in/out arguments). Will switch Xenomai to this scheme (which is also
easier readable) and will fold in the 32-bit version at this chance, too.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Petr Cervenka wrote:
>>>>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>>>>> identify which spot returns -EFAULT. I can't reproduce this issue on a
>>>>>>> ppc target; I may try over x86 later, but this would speed up things if
>>>>>>> you could spot the failing test before I'm able to switch to this.
>>>>>>>
>>>>>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>>>>>> But most attempts to confirm, that the value is returned by line:
>>>>>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>>>>>> 				NULL);
>>>>> This branches to __rt_task_create in kernel space.
>>>>>
>>>> The bulk variable is totally wrong in kernel space:
>>>> for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
>>>> It fails on following line (syscall.c:aprox. 193):
>>>> 	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {
>>>>
>>>>>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>>>>>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>>>>>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>>>>>> @@ -241,6 +241,7 @@
>>>>>>         pthread_setspecific(__native_tskey, NULL);
>>>>>>         free(self);
>>>>>>  #endif /* !HAVE___THREAD */
>>>>>> +       rt_task_set_mode(0, 0, NULL);
>>>>>>         return err;
>>>>>>  }
>>>>>>
>>>>>> objdumps of original and changed rt_task_shadow() is in attachment
>>>>>>
>>>>>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>>>>>>
>>>>> Try rebuilding the user-space libs passing --without-__thread to the
>>>>> configure script.
>>>>>
>>>> After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
>>>> Do you already know, where the problem is? What does the "--without-__thread" argument mean?
>>> It's reproducible, will try to understand it. It's either a compiler bug
>> That would be the second compiler bug with __thread (we have a bug on
>> arm). If we add this to the fact that supporting __thread clutters the
>> code with many #ifdefs, and does not improve performances on other
>> platforms than x86 where so many cycles are executed by nanosecond that
>> it does not matter that much, I'd say let's get rid of __thread.
>>
>> Besides, it really looks like C++ syntactic sugar where the compiler
>> makes things behind my back when I use a seemingly simple syntax, it
>> does not conform with what I would expect from a C compiler.
>>
> 
> TLS was just the catalyst. The x86_64 syscall interface is defined in a
> too fragile way. As Petr already noticed, the core of the problem is
> that the syscall argument &bulk does not reach the kernel. And if you
> look at the disassembly kubuntu's gcc-4.3.1 generates, it's obvious why:
> rdi is not initialized at all with &bulk. For some reason, the compiler
> thinks it could leave this out or rdi would already contain the correct
> address.

Just like the ARM bug.

-- 
					    Gilles.

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4590 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Petr Cervenka wrote:
>>>>>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>>>>>> identify which spot returns -EFAULT. I can't reproduce this issue on a
>>>>>>>> ppc target; I may try over x86 later, but this would speed up things if
>>>>>>>> you could spot the failing test before I'm able to switch to this.
>>>>>>>>
>>>>>>> Meanwhile I tried to mess little bit with rt_task_shadow() function to see, where is the source of -EFAULT. I planned to continue to follow it inside syscall etc.
>>>>>>> But most attempts to confirm, that the value is returned by line:
>>>>>>> 	err = XENOMAI_SKINCALL2(__native_muxid, __native_task_create, &bulk,
>>>>>>> 				NULL);
>>>>>> This branches to __rt_task_create in kernel space.
>>>>>>
>>>>> The bulk variable is totally wrong in kernel space:
>>>>> for example (2, 0, 0, 0, 0, 134217728), perhaps always same values. Value 2 could be number of arguments of the skincall.
>>>>> It fails on following line (syscall.c:aprox. 193):
>>>>> 	if (__xn_safe_copy_to_user((void __user *)bulk.a1, &ph, sizeof(ph))) {
>>>>>
>>>>>>> where suprisingly followed by correct behavior. For example following (nothing doing) change in the attached patch solves the whole thing:
>>>>>>> --- /usr/src/xenomai/src/skins/native/task2.c   2009-04-13 19:20:18.000000000 +0200
>>>>>>> +++ /usr/src/xenomai/src/skins/native/task.c    2009-07-17 15:06:20.000000000 +0200
>>>>>>> @@ -241,6 +241,7 @@
>>>>>>>         pthread_setspecific(__native_tskey, NULL);
>>>>>>>         free(self);
>>>>>>>  #endif /* !HAVE___THREAD */
>>>>>>> +       rt_task_set_mode(0, 0, NULL);
>>>>>>>         return err;
>>>>>>>  }
>>>>>>>
>>>>>>> objdumps of original and changed rt_task_shadow() is in attachment
>>>>>>>
>>>>>>> I will continue in research, but I'm really not good in dissasembling nor the register knowledge.
>>>>>>>
>>>>>> Try rebuilding the user-space libs passing --without-__thread to the
>>>>>> configure script.
>>>>>>
>>>>> After rebuilding with "./configure --enable-smp --without-__thread" it works without any problems.
>>>>> Do you already know, where the problem is? What does the "--without-__thread" argument mean?
>>>> It's reproducible, will try to understand it. It's either a compiler bug
>>> That would be the second compiler bug with __thread (we have a bug on
>>> arm). If we add this to the fact that supporting __thread clutters the
>>> code with many #ifdefs, and does not improve performances on other
>>> platforms than x86 where so many cycles are executed by nanosecond that
>>> it does not matter that much, I'd say let's get rid of __thread.
>>>
>>> Besides, it really looks like C++ syntactic sugar where the compiler
>>> makes things behind my back when I use a seemingly simple syntax, it
>>> does not conform with what I would expect from a C compiler.
>>>
>> TLS was just the catalyst. The x86_64 syscall interface is defined in a
>> too fragile way. As Petr already noticed, the core of the problem is
>> that the syscall argument &bulk does not reach the kernel. And if you
>> look at the disassembly kubuntu's gcc-4.3.1 generates, it's obvious why:
>> rdi is not initialized at all with &bulk. For some reason, the compiler
>> thinks it could leave this out or rdi would already contain the correct
>> address.
> 
> Just like the ARM bug.
> 

What was the precise brokenness you saw? Also a missing syscall argument
initialization? Can you easily reproduce the ARM issue? Would be
interesting to know if '+r' makes a difference there, too.

This is what the xen/hypercall.h states on the "+r":

>  * - Avoid compiler bugs.
>  *    This is the tricky part.  Because x86_32 has such a constrained
>  *    register set, gcc versions below 4.3 have trouble generating
>  *    code when all the arg registers and memory are trashed by the
>  *    asm.  There are syntactically simpler ways of achieving the
>  *    semantics below, but they cause the compiler to crash.
>  *
>  *    The only combination I found which works is:
>  *     - assign the __argX variables first
>  *     - list all actually used parameters as "+r" (__argX)
>  *     - clobber the rest

This does not really match to bug we see on x86_64, but it points into a
more or less similar direction (BTW, it was gcc 4.1.3 on kubuntu, not
4.3.1).

Is it possible that other arch (so far silently) suffer from such issues
with older gcc versions, too?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> What was the precise brokenness you saw? Also a missing syscall
> argument initialization? Can you easily reproduce the ARM issue?
> Would be

It is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815

The arm syscalls contain a workaround, I copy the values to some
temporary variables, but I can not make it work with the bugzilla sample
(though I am almost sure I tested it when I did it, I may have changed
toolchain version in the mean time).


> interesting to know if '+r' makes a difference there, too.

I tested it after you mention it, and no, it makes no difference.

-- 
					    Gilles.

Re: [Xenomai-help] rt_task_shadow returns always -EFAULT

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> What was the precise brokenness you saw? Also a missing syscall
>> argument initialization? Can you easily reproduce the ARM issue?
>> Would be
> 
> It is here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815
> 
> The arm syscalls contain a workaround, I copy the values to some
> temporary variables, but I can not make it work with the bugzilla sample
> (though I am almost sure I tested it when I did it, I may have changed
> toolchain version in the mean time).
> 
> 
>> interesting to know if '+r' makes a difference there, too.
> 
> I tested it after you mention it, and no, it makes no difference.
> 

Meanwhile I also had troubles with the "+r" approach and even more
aspects of the Xen way. But I found a different workaround, see the pull
request.

Also note that even removing all TLS references from rt_task_shadow made
no difference for me. So this was really a different kind of bug than
what you saw on ARM.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]