All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@petalogix.com>
To: Jiri Palecek <jpalecek@web.de>
Cc: vapier@gentoo.org, ltp-list@lists.sourceforge.net
Subject: Re: [LTP] clone tests fails
Date: Thu, 07 Jan 2010 15:12:07 +0100	[thread overview]
Message-ID: <4B45EBB7.6030201@petalogix.com> (raw)
In-Reply-To: <4B4534EB.5020306@web.de>

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

      reply	other threads:[~2010-01-07 14:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B45EBB7.6030201@petalogix.com \
    --to=michal.simek@petalogix.com \
    --cc=jpalecek@web.de \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.