Re: [LTP] clone tests fails

[Michal Simek <michal.simek@petalogix.com>]

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