From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/mprotect04: align exec_func to 64 bytes
Date: Mon, 11 Feb 2019 17:11:37 -0500 (EST) [thread overview]
Message-ID: <856912859.250579.1549923097312.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAE2F3rBjc_m_pRb_w2+iJoQpgcBUzxvhD2V23VMM2hK5wAjS8w@mail.gmail.com>
----- Original Message -----
> Consider consolidating page_sz (currently in get_func()) and copy_sz
> (global) since they are now identical. Maybe make page_sz a global
> variable.
>
> I had some concerns around "-falign-functions=64": For example,
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html states
> "Enabled at levels -O2, -O3.". The way I read this is that
> -falign-functions is ignored for optimization levels other than O2 and
> O3. An ad-hoc test with gcc 7.3.0, however, showed that functions are
> indeed aligned on 64 byte boundaries even with O0. I also tried clang
> (llvm), and it also behaves as desired (for x86-64 and aarch64).
>
> I guess one thing you could do is to calculate the difference between
> the address of exec_func and the end of the page and programmatically
> verify that there is enough cushion between the start of exec_func and
> the end of the page. This would catch the case where some compiler
> ignores "-falign-functions=64".
That sounds like reasonable precaution, I'll send v2 shortly.
>
> On Mon, Feb 11, 2019 at 7:04 AM Jan Stancek <jstancek@redhat.com> wrote:
> >
> > exec_func() is dummy/empty function. If we make sure it's aligned,
> > we can be pretty confident that it will located in single page and
> > can drop code that deals with 2nd page.
> >
> > Signed-off-by: Jan Stancek <jstancek@redhat.com>
> > ---
> > testcases/kernel/syscalls/mprotect/Makefile | 2 ++
> > testcases/kernel/syscalls/mprotect/mprotect04.c | 12 ++----------
> > 2 files changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/testcases/kernel/syscalls/mprotect/Makefile
> > b/testcases/kernel/syscalls/mprotect/Makefile
> > index bd617d806675..bc5c8bc10395 100644
> > --- a/testcases/kernel/syscalls/mprotect/Makefile
> > +++ b/testcases/kernel/syscalls/mprotect/Makefile
> > @@ -20,4 +20,6 @@ top_srcdir ?= ../../../..
> >
> > include $(top_srcdir)/include/mk/testcases.mk
> >
> > +mprotect04: CFLAGS += -falign-functions=64
> > +
> > include $(top_srcdir)/include/mk/generic_leaf_target.mk
> > diff --git a/testcases/kernel/syscalls/mprotect/mprotect04.c
> > b/testcases/kernel/syscalls/mprotect/mprotect04.c
> > index 60941a4220d5..3125f344795d 100644
> > --- a/testcases/kernel/syscalls/mprotect/mprotect04.c
> > +++ b/testcases/kernel/syscalls/mprotect/mprotect04.c
> > @@ -88,7 +88,7 @@ static void setup(void)
> > {
> > tst_tmpdir();
> > tst_sig(NOFORK, sighandler, cleanup);
> > - copy_sz = getpagesize() * 2;
> > + copy_sz = getpagesize();
> >
> > TEST_PAUSE;
> > }
> > @@ -133,7 +133,7 @@ static void testfunc_protnone(void)
> >
> > #ifdef __ia64__
> >
> > -static char exec_func[] = {
> > +static char exec_func[] __attribute__ ((aligned (64))) = {
> > 0x11, 0x00, 0x00, 0x00, 0x01, 0x00, /* nop.m 0x0 */
> > 0x00, 0x00, 0x00, 0x02, 0x00, 0x80, /* nop.i 0x0 */
> > 0x08, 0x00, 0x84, 0x00, /* br.ret.sptk.many b0;; */
> > @@ -237,14 +237,6 @@ static void *get_func(void *mem)
> > }
> > memcpy(mem, page_to_copy, page_sz);
> >
> > - /* copy 2nd page if possible */
> > - mem += page_sz;
> > - page_to_copy += page_sz;
> > - if (page_present(page_to_copy))
> > - memcpy(mem, page_to_copy, page_sz);
> > - else
> > - memset(mem, 0, page_sz);
> > -
> > clear_cache(mem_start, copy_sz);
> >
> > /* return pointer to area where copy of exec_func resides */
> > --
> > 1.8.3.1
> >
>
prev parent reply other threads:[~2019-02-11 22:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 15:03 [LTP] [PATCH] syscalls/mprotect04: align exec_func to 64 bytes Jan Stancek
2019-02-11 20:11 ` Daniel Mentz
2019-02-11 22:11 ` Jan Stancek [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=856912859.250579.1549923097312.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=ltp@lists.linux.it \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox