* [LTP] clone tests fails @ 2010-01-04 16:17 Michal Simek 2010-01-04 16:49 ` Serge E. Hallyn 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2010-01-04 16:17 UTC (permalink / raw) To: ltp-list@lists.sourceforge.net, vapier 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-04 16:17 [LTP] clone tests fails Michal Simek @ 2010-01-04 16:49 ` Serge E. Hallyn 2010-01-04 17:35 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Serge E. Hallyn @ 2010-01-04 16:49 UTC (permalink / raw) To: Michal Simek; +Cc: ltp-list, vapier 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-04 16:49 ` Serge E. Hallyn @ 2010-01-04 17:35 ` Michal Simek 2010-01-04 17:49 ` Serge E. Hallyn 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2010-01-04 17:35 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: ltp-list, vapier 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-04 17:35 ` Michal Simek @ 2010-01-04 17:49 ` Serge E. Hallyn 2010-01-06 1:05 ` Jiri Palecek 0 siblings, 1 reply; 14+ messages in thread From: Serge E. Hallyn @ 2010-01-04 17:49 UTC (permalink / raw) To: Michal Simek; +Cc: ltp-list, vapier 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-04 17:49 ` Serge E. Hallyn @ 2010-01-06 1:05 ` Jiri Palecek 2010-01-06 3:26 ` Serge E. Hallyn ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Jiri Palecek @ 2010-01-06 1:05 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: vapier, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 1:05 ` Jiri Palecek @ 2010-01-06 3:26 ` Serge E. Hallyn 2010-01-06 5:25 ` Mike Frysinger 2010-01-06 10:19 ` Michal Simek 2010-01-06 5:25 ` Mike Frysinger 2010-01-06 10:15 ` Michal Simek 2 siblings, 2 replies; 14+ messages in thread From: Serge E. Hallyn @ 2010-01-06 3:26 UTC (permalink / raw) To: Jiri Palecek; +Cc: Nathan T Lynch, vapier, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 3:26 ` Serge E. Hallyn @ 2010-01-06 5:25 ` Mike Frysinger 2010-01-07 1:25 ` Jiri Palecek 2010-01-06 10:19 ` Michal Simek 1 sibling, 1 reply; 14+ messages in thread From: Mike Frysinger @ 2010-01-06 5:25 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Jiri Palecek, Nathan T Lynch, ltp-list [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 5:25 ` Mike Frysinger @ 2010-01-07 1:25 ` Jiri Palecek 0 siblings, 0 replies; 14+ messages in thread From: Jiri Palecek @ 2010-01-07 1:25 UTC (permalink / raw) To: Mike Frysinger; +Cc: Nathan T Lynch, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 3:26 ` Serge E. Hallyn 2010-01-06 5:25 ` Mike Frysinger @ 2010-01-06 10:19 ` Michal Simek 1 sibling, 0 replies; 14+ messages in thread From: Michal Simek @ 2010-01-06 10:19 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Jiri Palecek, Nathan T Lynch, vapier, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 1:05 ` Jiri Palecek 2010-01-06 3:26 ` Serge E. Hallyn @ 2010-01-06 5:25 ` Mike Frysinger 2010-01-07 1:21 ` Jiri Palecek 2010-01-06 10:15 ` Michal Simek 2 siblings, 1 reply; 14+ messages in thread From: Mike Frysinger @ 2010-01-06 5:25 UTC (permalink / raw) To: Jiri Palecek; +Cc: ltp-list [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 5:25 ` Mike Frysinger @ 2010-01-07 1:21 ` Jiri Palecek 0 siblings, 0 replies; 14+ messages in thread From: Jiri Palecek @ 2010-01-07 1:21 UTC (permalink / raw) To: Mike Frysinger; +Cc: ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 1:05 ` Jiri Palecek 2010-01-06 3:26 ` Serge E. Hallyn 2010-01-06 5:25 ` Mike Frysinger @ 2010-01-06 10:15 ` Michal Simek 2010-01-07 1:12 ` Jiri Palecek 2 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2010-01-06 10:15 UTC (permalink / raw) To: Jiri Palecek; +Cc: vapier, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-06 10:15 ` Michal Simek @ 2010-01-07 1:12 ` Jiri Palecek 2010-01-07 14:12 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Jiri Palecek @ 2010-01-07 1:12 UTC (permalink / raw) To: michal.simek; +Cc: vapier, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [LTP] clone tests fails 2010-01-07 1:12 ` Jiri Palecek @ 2010-01-07 14:12 ` Michal Simek 0 siblings, 0 replies; 14+ messages in thread From: Michal Simek @ 2010-01-07 14:12 UTC (permalink / raw) To: Jiri Palecek; +Cc: vapier, ltp-list 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-01-07 14:13 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-01-04 16:17 [LTP] clone tests fails Michal Simek 2010-01-04 16:49 ` Serge E. Hallyn 2010-01-04 17:35 ` Michal Simek 2010-01-04 17:49 ` Serge E. Hallyn 2010-01-06 1:05 ` Jiri Palecek 2010-01-06 3:26 ` Serge E. Hallyn 2010-01-06 5:25 ` Mike Frysinger 2010-01-07 1:25 ` Jiri Palecek 2010-01-06 10:19 ` Michal Simek 2010-01-06 5:25 ` Mike Frysinger 2010-01-07 1:21 ` Jiri Palecek 2010-01-06 10:15 ` Michal Simek 2010-01-07 1:12 ` Jiri Palecek 2010-01-07 14:12 ` Michal Simek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox