clone tests fails
Hi Mike,
I have one question about one your big patch
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
Signature · 14 lines
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
Quoted 11 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65(quoted diff) +2
-0+ ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), + clone_flags, arg);
Quoted 2 lines
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.
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 9 lines · Serge E. Hallyn
Quoted 8 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65
Quoted 8 lines
Quoted 5 lines
(quoted diff) +2
-0+ 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
Quoted 7 lines
Quoted 2 lines
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
Signature · 14 lines
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
Quoted 16 lines · Michal Simek
Quoted 15 lines · Serge E. Hallyn
Quoted 13 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65(quoted diff) +2
-0+ 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?
Quoted 7 lines
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Serge E. Hallyn napsal(a):
Quoted 21 lines · Michal Simek
Quoted 20 lines
Quoted 17 lines · Serge E. Hallyn
Quoted 11 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65(quoted diff) +2
-0+ ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), + clone_flags, arg);Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 33 lines · Jiri Palecek
Serge E. Hallyn napsal(a):
Quoted 21 lines · Michal Simek
Quoted 20 lines
Quoted 17 lines · Serge E. Hallyn
Quoted 11 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65(quoted diff) +2
-0+ ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), + clone_flags, arg);Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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).
Quoted 6 lines
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
Quoted 6 lines · On Tuesday 05 January 2010 22:26:44 Serge E. Hallyn wrote:
Quoted 5 lines · Jiri Palecek
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).
Quoted 7 lines
Quoted 1 line
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
------------------------------------------------------------------------------
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
Mike Frysinger napsal(a):
Quoted 9 lines · On Tuesday 05 January 2010 22:26:44 Serge E. Hallyn wrote:
Quoted 8 lines · Jiri Palecek
Quoted 6 lines
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?
Quoted 7 lines
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 35 lines · Serge E. Hallyn
Quoted 34 lines · Jiri Palecek
Serge E. Hallyn napsal(a):
Quoted 16 lines · Michal Simek
Quoted 15 lines
Quoted 14 lines · Serge E. Hallyn
Quoted 13 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65(quoted diff) +2
-0+ 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?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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).
Quoted 7 lines
Quoted 1 line
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
Quoted 2 lines
-serge
Signature · 14 lines
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
Quoted 5 lines · 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
------------------------------------------------------------------------------
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
Mike Frysinger napsal(a):
Quoted 8 lines · On Tuesday 05 January 2010 20:05:17 Jiri Palecek wrote:
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 30 lines · Jiri Palecek
Serge E. Hallyn napsal(a):
Quoted 22 lines · Michal Simek
Quoted 21 lines
Quoted 18 lines · Serge E. Hallyn
Quoted 12 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
My question is why you add -1 in
lib/cloner.c:65(quoted diff) +2
-0+ ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), + clone_flags, arg);Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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
Quoted 5 lines
Perhaps both of these behaviors should be tested by LTP?
Regards
Jiri Palecek
Signature · 14 lines
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
Michal Simek napsal(a):
Quoted 44 lines
Quoted 30 lines · Jiri Palecek
Serge E. Hallyn napsal(a):
Quoted 22 lines · Michal Simek
Quoted 21 lines
Quoted 18 lines · Serge E. Hallyn
Quoted 7 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
Quoted 7 lines
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.
Quoted 6 lines
Quoted 3 lines
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.Quoted 8 lines
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_sizeexceed.
Quoted 14 lines
# ./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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
Quoted 61 lines · Jiri Palecek
Michal Simek napsal(a):
Quoted 45 lines
Quoted 31 lines · Jiri Palecek
Serge E. Hallyn napsal(a):
Quoted 23 lines · Michal Simek
Quoted 22 lines
Quoted 19 lines · Serge E. Hallyn
Quoted 8 lines · Michal Simek
Hi Mike,
I have one question about one your big patch
Quoted 7 lines
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.
Quoted 6 lines
Quoted 3 lines
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.Quoted 8 lines
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_sizeexceed.Quoted 14 lines
# ./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
Quoted 6 lines
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_sizeexceeded 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 toltp_clone, subtract 1 inltp_cloneand so on).
It is just reaction on unaligned access. if is aligned then system has no problem.
Thanks,
Michal
Quoted 3 lines
Regards
Jiri Palecek
Signature · 14 lines
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