Quoting Jiri Palecek ([email protected]):
> Serge E. Hallyn napsal(a):
> >Quoting Michal Simek ([email protected]):
> >>Serge E. Hallyn wrote:
> >>>Quoting Michal Simek ([email protected]):
> >>>>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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
