All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carmelo AMOROSO <carmelo.amoroso@st.com>
To: Hannu Heikkinen <hannuxx@iki.fi>
Cc: "ltp-list@lists.sourceforge.net" <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] ltp_clone alignment issues.
Date: Mon, 4 Oct 2010 15:04:43 +0200	[thread overview]
Message-ID: <4CA9D0EB.5090309@st.com> (raw)
In-Reply-To: <20101001040609.GA2090@hannu-ubuntu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/1/2010 6:06 AM, Hannu Heikkinen wrote:
> On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
> On 9/30/2010 3:31 PM, Hannu Heikkinen wrote:
>> On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote:
>> > > Folks,
>> > > I want to reopen an old discussion on ltp_clone and stack alignment
>> > > issue (see
>> > >
> 
>> http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com).
>> > > Indeed recently a commit has partially fixed a problem on ARM
>> > > (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be
>> > > extended to all archs that have stack that grows downwards.
>> > >
>> > > Indeed, as Jiri replied in that old thread, the value passed to clone as
>> > > child stack should be never accessed, because it is the topmost address
>> > > of the memory allocated for the child process (it's the previous stack
>> > > pointer).
>> > >
>> > > So, in archs that do not like unaligned stack, using (stack - size - 1 )
>> > > will cause the process to be killed by a SIGBUS, on other archs, we are
>> > > just wasting one byte of the malloc-ed stack.
>> > >
>> > > On my SH4 arch, the stack must be 4byte aligned (as in ARM).
>> > >
>> > > Please, find attached a patch against master branch
>> > >
>> > > Best regards,
>> > > Carmelo
>> >
>> > Hi,
>> > any feedback on this ?
>> >
>> > Cheers,
>> > Carmelo
> 
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
>> ---
>> lib/cloner.c | 9 +++------
>> 1 files changed, 3 insertions(+), 6 deletions(-)
> 
>> diff --git a/lib/cloner.c b/lib/cloner.c
>> index 6ad4a00..e53c9cf 100644
>> --- a/lib/cloner.c
>> +++ b/lib/cloner.c
>> @@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void
>> *arg), void *arg,
>> ret = clone(fn, stack, clone_flags, arg);
>> #elif defined(__ia64__)
>> ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
>> NULL);
>> -#elif defined(__arm__)
>> +#else
>> /*
>> - * Stack size should be a multiple of 32 bit words
>> - * & stack limit must be aligned to a 32 bit boundary
>> + * For archs where stack grows downwards, stack points to the topmost
>> address
>> + * of the memory space set up for the child stack.
>> */
>> ret = clone(fn, (stack ? stack + stack_size : NULL),
>> clone_flags, arg);
>> -#else
>> - ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
>> - clone_flags, arg);
>> #endif
> 
>> return ret;
>> --
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
>> Hi,
> 
>> Acked-by Hannu Heikkinen <ext-hannu.m.heikkinen@nokia.com>
> 
>> Br,
>> Hannu
> 
>> --
>> Hannu Heikkinen
>> http://www.nixu.com
> 
> 
> Thanks, Hannu

> Hi,

> I was thinking your patch once again, and I think it would be wiser if
> we would have something like:

> --- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.000000000
> +0300
> +++ lib/cloner.c 2010-09-03 14:48:20.000000000 +0300
> @@ -43,6 +43,16 @@
> pid_t *parent_tid, void *tls, pid_t *child_tid);
> #endif

> +/*
> + * Most arch really want to have stack aligned to some sane boundary.
> + */
> +#ifdef __arm__
> +#define ALIGN_STACK(stack) \
> + ((void *)(((unsigned long)stack) & ~((sizeof(void *)) - 1)))
> +#else
> +#define ALIGN_STACK(stack) (stack)
> +#endif
> +
> /***********************************************************************
> * ltp_clone: wrapper for clone to hide the architecture dependencies.
> * 1. hppa takes bottom of stack and no stacksize (stack grows up)
> @@ -60,7 +70,7 @@
> #elif defined(__ia64__)
> ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL,
> NULL);
> #else
> - ret = clone(fn, (stack ? stack + stack_size - 1 : NULL),
> + ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL),
> clone_flags, arg);
> #endif


> The above patch iis in use in our ARM based LTP test suite. Note that -1 is
> needed for not clobbering eg possibly malloced area after child stack.
> Could u please change that prev patch a bit, for ensuring that child stack
> is in proper size etc. Above patch is not sufficient, because ALIGN_STACK
> in that is only used for arm archs.

> br,
> Hannu


Hannu,
I don't think that it is a good to force the alignment; we could need to
write a test case that calls LTP_clone with an unaligned stack just to
test the behavior of the clone implementation.

Likely, it should be useful to add a check inside the C lib clone
implementation (arch specific) to protect against unaligned stack, but
this is a different matter.

I would just leave the LTP_clone passing the argument to the clone as
they came from the caller.

Regards,
Carmelo


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyp0OsACgkQoRq/3BrK1s+TPwCgnoZlDNW0yMjfLZAu6gKzywP7
Bp4AoLpYpxtqjtd+tL4+ZpxNhnQv7fpF
=VGJo
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  reply	other threads:[~2010-10-04 13:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-27 13:34 [LTP] ltp_clone alignment issues Carmelo AMOROSO
2010-09-29 13:34 ` Carmelo AMOROSO
2010-09-30 13:31   ` Hannu Heikkinen
2010-09-30 10:42     ` Carmelo AMOROSO
2010-10-01  4:06       ` Hannu Heikkinen
2010-10-04 13:04         ` Carmelo AMOROSO [this message]
2010-10-04 13:28           ` Garrett Cooper
2010-10-04 19:09             ` Hannu Heikkinen
2010-10-04 20:00             ` Hannu Heikkinen
2010-10-04 20:57               ` Garrett Cooper
2010-10-05  6:05             ` Carmelo AMOROSO
2010-10-04 19:05           ` Hannu Heikkinen
2010-11-09 11:24             ` Carmelo AMOROSO
2010-11-11  7:57               ` Subrata Modak
2010-11-11  8:08                 ` Carmelo AMOROSO
2010-11-11  9:59                   ` Garrett Cooper
2010-11-15  7:29                     ` Carmelo AMOROSO
2010-11-21  3:34                       ` Garrett Cooper
2010-11-24  8:30                         ` Carmelo AMOROSO
2010-11-24  8:44                           ` Garrett Cooper

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=4CA9D0EB.5090309@st.com \
    --to=carmelo.amoroso@st.com \
    --cc=hannuxx@iki.fi \
    --cc=ltp-list@lists.sourceforge.net \
    /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.