Re: [LTP] clone tests fails
Jiri Palecek wrote: Michal Simek napsal(a): Jiri Palecek wrote: Serge E. Hallyn napsal(a): Quoting Michal Simek (michal.si...@petalogix.com): Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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. h. 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, 0x, 0xc000 Oops: Exception in kernel mode, sig: 11 Registers dump: mode=1 r1=CDC3FF50, r2=, r3=08A1, r4= r5=, r6=0800, r7=CDC3FF68, r8=0028 r9=481804AC, r10=, r11=45AA, r12=C00011C4 r13=, r14=6B6B6B6B, r15=C00083F8, r16=6B6B6B6B r17=6B6B6B6B, r18=, r19=, r20=100074C8 r21=, r22=100073CC, r23=, r24= r25=1000C050, r26=0001, r27=10005310, r28=10001060 r29=, r30=, r31=CDD4C358, rPC=C00011DC msr=45AA, ear=, esr=00B2, 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
Re: [LTP] clone tests fails
Jiri Palecek wrote: Serge E. Hallyn napsal(a): Quoting Michal Simek (michal.si...@petalogix.com): Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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. h. 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, 0x, 0xc000 Oops: Exception in kernel mode, sig: 11 Registers dump: mode=1 r1=CDC3FF50, r2=, r3=08A1, r4= r5=, r6=0800, r7=CDC3FF68, r8=0028 r9=481804AC, r10=, r11=45AA, r12=C00011C4 r13=, r14=6B6B6B6B, r15=C00083F8, r16=6B6B6B6B r17=6B6B6B6B, r18=, r19=, r20=100074C8 r21=, r22=100073CC, r23=, r24= r25=1000C050, r26=0001, r27=10005310, r28=10001060 r29=, r30=, r31=CDD4C358, rPC=C00011DC msr=45AA, ear=, esr=00B2, 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
Serge E. Hallyn wrote: Quoting Jiri Palecek (jpale...@web.de): Serge E. Hallyn napsal(a): Quoting Michal Simek (michal.si...@petalogix.com): Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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. h. 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
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
Mike Frysinger napsal(a): On Tuesday 05 January 2010 22:26:44 Serge E. Hallyn wrote: Quoting Jiri Palecek (jpale...@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
Serge E. Hallyn napsal(a): Quoting Michal Simek (michal.si...@petalogix.com): Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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. h. 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
Quoting Jiri Palecek (jpale...@web.de): Serge E. Hallyn napsal(a): Quoting Michal Simek (michal.si...@petalogix.com): Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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. h. 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
On Tuesday 05 January 2010 22:26:44 Serge E. Hallyn wrote: Quoting Jiri Palecek (jpale...@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 signature.asc Description: This is a digitally signed message part. -- 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
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 signature.asc Description: This is a digitally signed message part. -- 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
[LTP] clone tests fails
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
Quoting Michal Simek (michal.si...@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
Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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
Quoting Michal Simek (michal.si...@petalogix.com): Serge E. Hallyn wrote: Quoting Michal Simek (michal.si...@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. h. 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
