Serge E. Hallyn wrote: > 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 > ?
(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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
