[LTP] clone tests fails

[LTP] clone tests fails

[Michal Simek]

Hi Mike,

I have one question about one your big patch

http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018

My question is why you add -1 in lib/cloner.c:65

+       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
+                       clone_flags, arg);

In previous code in clone testcases was nothing like this.
What reason have you had to add it?

Of course the reason is that on Microblaze some tests failed.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Serge E. Hallyn]

Quoting Michal Simek (michal.simek@petalogix.com):
> Hi Mike,
> 
> I have one question about one your big patch
> 
> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
> 
> My question is why you add -1 in lib/cloner.c:65
> 
> +       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
> +                       clone_flags, arg);
> 
> In previous code in clone testcases was nothing like this.
> What reason have you had to add it?

Because the same thing was done in lots of places all over the
testsuite (and done wrong).  This consolidates them all.

> Of course the reason is that on Microblaze some tests failed.

How do they fail?  Does clone on Microblaze take the top of
stack?

-serge

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Michal Simek]

Serge E. Hallyn wrote:
> Quoting Michal Simek (michal.simek@petalogix.com):
>> Hi Mike,
>>
>> I have one question about one your big patch
>>
>> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
>>
>> My question is why you add -1 in lib/cloner.c:65
>>
>> +       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>> +                       clone_flags, arg);
>>
>> In previous code in clone testcases was nothing like this.
>> What reason have you had to add it?
> 
> Because the same thing was done in lots of places all over the
> testsuite (and done wrong).  This consolidates them all.


I don't have anything against consolidation. I just want to know why 
there is that -1 which weren't in any clone testcases. Nothing more 
nothing less.

Michal

> 
>> Of course the reason is that on Microblaze some tests failed.
> 
> How do they fail?  Does clone on Microblaze take the top of
> stack?
> 
> -serge


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Serge E. Hallyn]

Quoting Michal Simek (michal.simek@petalogix.com):
> Serge E. Hallyn wrote:
> >Quoting Michal Simek (michal.simek@petalogix.com):
> >>Hi Mike,
> >>
> >>I have one question about one your big patch
> >>
> >>http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
> >>
> >>My question is why you add -1 in lib/cloner.c:65
> >>
> >>+       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
> >>+                       clone_flags, arg);
> >>
> >>In previous code in clone testcases was nothing like this.
> >>What reason have you had to add it?
> >
> >Because the same thing was done in lots of places all over the
> >testsuite (and done wrong).  This consolidates them all.
> 
> 
> I don't have anything against consolidation. I just want to know why
> there is that -1 which weren't in any clone testcases. Nothing more
> nothing less.

ooooh.  Because if we've done stack = malloc(stack_size), then
stack+stack_size is 1 above the the top of stack.

-serge

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Jiri Palecek]

Serge E. Hallyn napsal(a):
> Quoting Michal Simek (michal.simek@petalogix.com):
>> Serge E. Hallyn wrote:
>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>> Hi Mike,
>>>>
>>>> I have one question about one your big patch
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
>>>>
>>>> My question is why you add -1 in lib/cloner.c:65
>>>>
>>>> +       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>>>> +                       clone_flags, arg);
>>>>
>>>> In previous code in clone testcases was nothing like this.
>>>> What reason have you had to add it?
>>>
>>> Because the same thing was done in lots of places all over the
>>> testsuite (and done wrong).  This consolidates them all.
>>
>>
>> I don't have anything against consolidation. I just want to know why
>> there is that -1 which weren't in any clone testcases. Nothing more
>> nothing less.
>
> ooooh.  Because if we've done stack = malloc(stack_size), then
> stack+stack_size is 1 above the the top of stack.

If the value of the parameter is the stack pointer of the created thread, it 
shouldn't matter - the address should never be used (read or written).

Michal, I suspect the failures you see are somehow related to alignment (that 
your architecture doesn't like odd addresses). Is that right? Under x86, the 
address gets aligned (so some of the space is unused).

Perhaps both of these behaviors should be tested by LTP?

Regards
     Jiri Palecek

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Serge E. Hallyn]

Quoting Jiri Palecek (jpalecek@web.de):
> Serge E. Hallyn napsal(a):
> >Quoting Michal Simek (michal.simek@petalogix.com):
> >>Serge E. Hallyn wrote:
> >>>Quoting Michal Simek (michal.simek@petalogix.com):
> >>>>Hi Mike,
> >>>>
> >>>>I have one question about one your big patch
> >>>>
> >>>>http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
> >>>>
> >>>>My question is why you add -1 in lib/cloner.c:65
> >>>>
> >>>>+       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
> >>>>+                       clone_flags, arg);
> >>>>
> >>>>In previous code in clone testcases was nothing like this.
> >>>>What reason have you had to add it?
> >>>
> >>>Because the same thing was done in lots of places all over the
> >>>testsuite (and done wrong).  This consolidates them all.
> >>
> >>
> >>I don't have anything against consolidation. I just want to know why
> >>there is that -1 which weren't in any clone testcases. Nothing more
> >>nothing less.
> >
> >ooooh.  Because if we've done stack = malloc(stack_size), then
> >stack+stack_size is 1 above the the top of stack.
> 
> If the value of the parameter is the stack pointer of the created
> thread, it shouldn't matter - the address should never be used (read
> or written).
> 
> Michal, I suspect the failures you see are somehow related to
> alignment (that your architecture doesn't like odd addresses). Is
> that right? Under x86, the address gets aligned (so some of the
> space is unused).
> 
> Perhaps both of these behaviors should be tested by LTP?

Gah, yes, Nathan had mentioned arches where this matters (including
some power?).  Nathan, did you have a generic fix for this in
userspace?  Should always be safe to do
	(stack + stack_size - 1) & ~0xf
?

-serge

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 692 bytes --]

On Tuesday 05 January 2010 22:26:44 Serge E. Hallyn wrote:
> Quoting Jiri Palecek (jpalecek@web.de):
> > Michal, I suspect the failures you see are somehow related to
> > alignment (that your architecture doesn't like odd addresses). Is
> > that right? Under x86, the address gets aligned (so some of the
> > space is unused).
> >
> > Perhaps both of these behaviors should be tested by LTP?
> 
> Gah, yes, Nathan had mentioned arches where this matters (including
> some power?).  Nathan, did you have a generic fix for this in
> userspace?  Should always be safe to do
> 	(stack + stack_size - 1) & ~0xf
> ?

(sizeof(long double)-1) would probably be better than 0xf
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 390 bytes --]

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 406 bytes --]

On Tuesday 05 January 2010 20:05:17 Jiri Palecek wrote:
> Michal, I suspect the failures you see are somehow related to alignment
>  (that your architecture doesn't like odd addresses). Is that right? Under
>  x86, the address gets aligned (so some of the space is unused).
> 
> Perhaps both of these behaviors should be tested by LTP?

i dont think such tests would be reliable or useful ?
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 390 bytes --]

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Michal Simek]

Jiri Palecek wrote:
> Serge E. Hallyn napsal(a):
>> Quoting Michal Simek (michal.simek@petalogix.com):
>>> Serge E. Hallyn wrote:
>>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>>> Hi Mike,
>>>>>
>>>>> I have one question about one your big patch
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018 
>>>>>
>>>>>
>>>>> My question is why you add -1 in lib/cloner.c:65
>>>>>
>>>>> +       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>>>>> +                       clone_flags, arg);
>>>>>
>>>>> In previous code in clone testcases was nothing like this.
>>>>> What reason have you had to add it?
>>>>
>>>> Because the same thing was done in lots of places all over the
>>>> testsuite (and done wrong).  This consolidates them all.
>>>
>>>
>>> I don't have anything against consolidation. I just want to know why
>>> there is that -1 which weren't in any clone testcases. Nothing more
>>> nothing less.
>>
>> ooooh.  Because if we've done stack = malloc(stack_size), then
>> stack+stack_size is 1 above the the top of stack.
> 
> If the value of the parameter is the stack pointer of the created 
> thread, it shouldn't matter - the address should never be used (read or 
> written).
> 
> Michal, I suspect the failures you see are somehow related to alignment 
> (that your architecture doesn't like odd addresses). Is that right? 
> Under x86, the address gets aligned (so some of the space is unused).

yes, alignment is problem. I need to subtract at least -4.

As you can see below I am getting fault in kernel about task_size exceed.

# ./clone01
kernel task_size exceed, 0xffffffff, 0xc0000000
Oops: Exception in kernel mode, sig: 11
  Registers dump: mode=1
  r1=CDC3FF50, r2=00000000, r3=000008A1, r4=FFFFFFFF
  r5=00000000, r6=00000800, r7=CDC3FF68, r8=00000028
  r9=481804AC, r10=00000000, r11=000045AA, r12=C00011C4
  r13=00000000, r14=6B6B6B6B, r15=C00083F8, r16=6B6B6B6B
  r17=6B6B6B6B, r18=00000000, r19=FFFFFFFF, r20=100074C8
  r21=00000000, r22=100073CC, r23=00000000, r24=00000000
  r25=1000C050, r26=00000001, r27=10005310, r28=10001060
  r29=00000000, r30=00000000, r31=CDD4C358, rPC=C00011DC
  msr=000045AA, ear=FFFFFFFF, esr=000000B2, fsr=10005310
clone01     1  TPASS  :  clone() returned 66

Michal


> 
> Perhaps both of these behaviors should be tested by LTP?
> 
> Regards
>     Jiri Palecek


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Michal Simek]

Serge E. Hallyn wrote:
> Quoting Jiri Palecek (jpalecek@web.de):
>> Serge E. Hallyn napsal(a):
>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>> Serge E. Hallyn wrote:
>>>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>>>> Hi Mike,
>>>>>>
>>>>>> I have one question about one your big patch
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
>>>>>>
>>>>>> My question is why you add -1 in lib/cloner.c:65
>>>>>>
>>>>>> +       ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>>>>>> +                       clone_flags, arg);
>>>>>>
>>>>>> In previous code in clone testcases was nothing like this.
>>>>>> What reason have you had to add it?
>>>>> Because the same thing was done in lots of places all over the
>>>>> testsuite (and done wrong).  This consolidates them all.
>>>>
>>>> I don't have anything against consolidation. I just want to know why
>>>> there is that -1 which weren't in any clone testcases. Nothing more
>>>> nothing less.
>>> ooooh.  Because if we've done stack = malloc(stack_size), then
>>> stack+stack_size is 1 above the the top of stack.
>> If the value of the parameter is the stack pointer of the created
>> thread, it shouldn't matter - the address should never be used (read
>> or written).
>>
>> Michal, I suspect the failures you see are somehow related to
>> alignment (that your architecture doesn't like odd addresses). Is
>> that right? Under x86, the address gets aligned (so some of the
>> space is unused).
>>
>> Perhaps both of these behaviors should be tested by LTP?
> 
> Gah, yes, Nathan had mentioned arches where this matters (including
> some power?).  Nathan, did you have a generic fix for this in
> userspace?  Should always be safe to do
> 	(stack + stack_size - 1) & ~0xf
> ?

(long)(stack + stack_size - 1) & ~0x3

0x3 is enough - just clear last 2 bits.
I am not sure about long type - maybe need long long or long double.

Mike's solution not work for me.

Thanks,
Michal






> 
> -serge


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Jiri Palecek]

Michal Simek napsal(a):
> Jiri Palecek wrote:
>> Serge E. Hallyn napsal(a):
>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>> Serge E. Hallyn wrote:
>>>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>>>> Hi Mike,
>>>>>>
>>>>>> I have one question about one your big patch
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018
>>>>>>
>>>>>>
>>>>>> My question is why you add -1 in lib/cloner.c:65
>>>>>>
>>>>>> + ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>>>>>> + clone_flags, arg);
>>>>>>
>>>>>> In previous code in clone testcases was nothing like this.
>>>>>> What reason have you had to add it?
>>>>>
>>>>> Because the same thing was done in lots of places all over the
>>>>> testsuite (and done wrong). This consolidates them all.
>>>>
>>>>
>>>> I don't have anything against consolidation. I just want to know why
>>>> there is that -1 which weren't in any clone testcases. Nothing more
>>>> nothing less.
>>>
>>> ooooh. Because if we've done stack = malloc(stack_size), then
>>> stack+stack_size is 1 above the the top of stack.
>>
>> If the value of the parameter is the stack pointer of the created
>> thread, it shouldn't matter - the address should never be used (read
>> or written).
>>
>> Michal, I suspect the failures you see are somehow related to
>> alignment (that your architecture doesn't like odd addresses). Is that
>> right? Under x86, the address gets aligned (so some of the space is
>> unused).
>
> yes, alignment is problem. I need to subtract at least -4.
>
> As you can see below I am getting fault in kernel about task_size exceed.
>
> # ./clone01
> kernel task_size exceed, 0xffffffff, 0xc0000000
> Oops: Exception in kernel mode, sig: 11
> Registers dump: mode=1
> r1=CDC3FF50, r2=00000000, r3=000008A1, r4=FFFFFFFF
> r5=00000000, r6=00000800, r7=CDC3FF68, r8=00000028
> r9=481804AC, r10=00000000, r11=000045AA, r12=C00011C4
> r13=00000000, r14=6B6B6B6B, r15=C00083F8, r16=6B6B6B6B
> r17=6B6B6B6B, r18=00000000, r19=FFFFFFFF, r20=100074C8
> r21=00000000, r22=100073CC, r23=00000000, r24=00000000
> r25=1000C050, r26=00000001, r27=10005310, r28=10001060
> r29=00000000, r30=00000000, r31=CDD4C358, rPC=C00011DC
> msr=000045AA, ear=FFFFFFFF, esr=000000B2, fsr=10005310
> clone01 1 TPASS : clone() returned 66

I do not understand this dump fully, but couldn't it be just that your arch 
needs the 4 bytes of memory above what you pass as stack top (task_size exceeded 
should mean you accessed some address outside userspace)? Could you please test 
this by trying to run the tests with stack_size%4 != 0 (eg. pass PAGE_SIZE+1 to 
ltp_clone, subtract 1 in ltp_clone and so on).

Regards
     Jiri Palecek

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Jiri Palecek]

Mike Frysinger napsal(a):
> On Tuesday 05 January 2010 20:05:17 Jiri Palecek wrote:
>> Michal, I suspect the failures you see are somehow related to alignment
>>   (that your architecture doesn't like odd addresses). Is that right? Under
>>   x86, the address gets aligned (so some of the space is unused).
>>
>> Perhaps both of these behaviors should be tested by LTP?
>
> i dont think such tests would be reliable or useful ?

I don't think so. The set of addresses that can be successfully passed to 
clone() and the actual space the stack will occupy with the given parameters are 
definitely part of the interface (because the user cannot use the interface 
correctly without knowing these), therefore testing them is useful, and they 
should be quite easily testable, although the test would be 
architecture-dependent, but oh well, so is the whole clone() syscall.

Regards
     Jiri Palecek

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Jiri Palecek]

Mike Frysinger napsal(a):
> On Tuesday 05 January 2010 22:26:44 Serge E. Hallyn wrote:
>> Quoting Jiri Palecek (jpalecek@web.de):
>>> Michal, I suspect the failures you see are somehow related to
>>> alignment (that your architecture doesn't like odd addresses). Is
>>> that right? Under x86, the address gets aligned (so some of the
>>> space is unused).
>>>
>>> Perhaps both of these behaviors should be tested by LTP?
>>
>> Gah, yes, Nathan had mentioned arches where this matters (including
>> some power?).  Nathan, did you have a generic fix for this in
>> userspace?  Should always be safe to do
>> 	(stack + stack_size - 1)&  ~0xf
>> ?
>
> (sizeof(long double)-1) would probably be better than 0xf

sizeof(long double) is not a power of 2 (at least on 386), so this wouldn't 
probably work. glibc hardcodes the alignment (to 16 on most arches).

   Jiri Palecek


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] clone tests fails

[Michal Simek]

Jiri Palecek wrote:
> Michal Simek napsal(a):
>> Jiri Palecek wrote:
>>> Serge E. Hallyn napsal(a):
>>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>>> Serge E. Hallyn wrote:
>>>>>> Quoting Michal Simek (michal.simek@petalogix.com):
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> I have one question about one your big patch
>>>>>>>
>>>>>>> http://git.kernel.org/?p=linux/kernel/git/galak/ltp.git;a=commitdiff;h=391dc18fe3271fbf2ca1864a5299f091c31e0018 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My question is why you add -1 in lib/cloner.c:65
>>>>>>>
>>>>>>> + ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>>>>>>> + clone_flags, arg);
>>>>>>>
>>>>>>> In previous code in clone testcases was nothing like this.
>>>>>>> What reason have you had to add it?
>>>>>>
>>>>>> Because the same thing was done in lots of places all over the
>>>>>> testsuite (and done wrong). This consolidates them all.
>>>>>
>>>>>
>>>>> I don't have anything against consolidation. I just want to know why
>>>>> there is that -1 which weren't in any clone testcases. Nothing more
>>>>> nothing less.
>>>>
>>>> ooooh. Because if we've done stack = malloc(stack_size), then
>>>> stack+stack_size is 1 above the the top of stack.
>>>
>>> If the value of the parameter is the stack pointer of the created
>>> thread, it shouldn't matter - the address should never be used (read
>>> or written).
>>>
>>> Michal, I suspect the failures you see are somehow related to
>>> alignment (that your architecture doesn't like odd addresses). Is that
>>> right? Under x86, the address gets aligned (so some of the space is
>>> unused).
>>
>> yes, alignment is problem. I need to subtract at least -4.
>>
>> As you can see below I am getting fault in kernel about task_size exceed.
>>
>> # ./clone01
>> kernel task_size exceed, 0xffffffff, 0xc0000000
>> Oops: Exception in kernel mode, sig: 11
>> Registers dump: mode=1
>> r1=CDC3FF50, r2=00000000, r3=000008A1, r4=FFFFFFFF
>> r5=00000000, r6=00000800, r7=CDC3FF68, r8=00000028
>> r9=481804AC, r10=00000000, r11=000045AA, r12=C00011C4
>> r13=00000000, r14=6B6B6B6B, r15=C00083F8, r16=6B6B6B6B
>> r17=6B6B6B6B, r18=00000000, r19=FFFFFFFF, r20=100074C8
>> r21=00000000, r22=100073CC, r23=00000000, r24=00000000
>> r25=1000C050, r26=00000001, r27=10005310, r28=10001060
>> r29=00000000, r30=00000000, r31=CDD4C358, rPC=C00011DC
>> msr=000045AA, ear=FFFFFFFF, esr=000000B2, fsr=10005310
>> clone01 1 TPASS : clone() returned 66
> 
> I do not understand this dump fully, but couldn't it be just that your 
> arch needs the 4 bytes of memory above what you pass as stack top 
> (task_size exceeded should mean you accessed some address outside 
> userspace)? Could you please test this by trying to run the tests with 
> stack_size%4 != 0 (eg. pass PAGE_SIZE+1 to ltp_clone, subtract 1 in 
> ltp_clone and so on).

It is just reaction on unaligned access. if is aligned then system has 
no problem.

Thanks,
Michal

> 
> Regards
>     Jiri Palecek


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list