From: Hannu Heikkinen <hannuxx@iki.fi>
To: Carmelo AMOROSO <carmelo.amoroso@st.com>
Cc: "ltp-list@lists.sourceforge.net" <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] ltp_clone alignment issues.
Date: Fri, 1 Oct 2010 07:06:09 +0300 [thread overview]
Message-ID: <20101001040609.GA2090@hannu-ubuntu> (raw)
In-Reply-To: <4CA469A0.5090700@st.com>
On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkykaaAACgkQoRq/3BrK1s9XQQCgqFuIf0UtZVE2cIY07ZY+6PrN
> pmwAnRP5T4nCrFDwre+9VEwJ7WB6r0em
> =w2Z8
> -----END PGP SIGNATURE-----
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
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2010-10-01 4:06 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 [this message]
2010-10-04 13:04 ` Carmelo AMOROSO
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=20101001040609.GA2090@hannu-ubuntu \
--to=hannuxx@iki.fi \
--cc=carmelo.amoroso@st.com \
--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.