From: David Howells <dhowells@redhat.com>
To: torvalds@osdl.org, akpm@linux-foundation.org
Cc: bernds_cb1@t-online.de, dhowells@redhat.com,
rgetz@blackfin.uclinux.org, vapier.adi@gmail.com,
lethal@linux-sh.org, linux-kernel@vger.kernel.org
Subject: [PATCH 07/10] FDPIC: Don't attempt to expand the userspace stack to fill the space allocated [ver #3]
Date: Thu, 08 Jan 2009 12:54:22 +0000 [thread overview]
Message-ID: <20090108125422.28454.99617.stgit@warthog.procyon.org.uk> (raw)
In-Reply-To: <20090108125346.28454.90871.stgit@warthog.procyon.org.uk>
Stop the ELF-FDPIC binfmt from attempting to expand the userspace stack and brk
segments to fill the space actually allocated for it. The space allocated may
be rounded up by mmap(), and may be wasted.
However, finding out how much space we actually obtained uses the contentious
kobjsize() function which we'd like to get rid of as it doesn't necessarily
work for all slab allocators.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Mike Frysinger <vapier.adi@gmail.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
---
fs/binfmt_elf_fdpic.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 22baf1b..f3e72c5 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -168,9 +168,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
struct elf_fdpic_params exec_params, interp_params;
struct elf_phdr *phdr;
unsigned long stack_size, entryaddr;
-#ifndef CONFIG_MMU
- unsigned long fullsize;
-#endif
#ifdef ELF_FDPIC_PLAT_INIT
unsigned long dynaddr;
#endif
@@ -390,11 +387,6 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
goto error_kill;
}
- /* expand the stack mapping to use up the entire allocation granule */
- fullsize = kobjsize((char *) current->mm->start_brk);
- if (!IS_ERR_VALUE(do_mremap(current->mm->start_brk, stack_size,
- fullsize, 0, 0)))
- stack_size = fullsize;
up_write(¤t->mm->mmap_sem);
current->mm->brk = current->mm->start_brk;
next prev parent reply other threads:[~2009-01-08 12:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-08 12:53 [PATCH 00/10] Alter NOMMU mmap handling " David Howells
2009-01-08 12:53 ` [PATCH 01/10] NOMMU: Fix cleanup handling in ramfs_nommu_get_umapped_area() " David Howells
2009-01-08 12:53 ` [PATCH 02/10] NOMMU: Rename ARM's struct vm_region " David Howells
2009-01-08 12:54 ` [PATCH 03/10] NOMMU: Delete askedalloc and realalloc variables " David Howells
2009-01-08 12:54 ` [PATCH 04/10] NOMMU: Make VMAs per MM as for MMU-mode linux " David Howells
2009-01-13 7:55 ` Andrew Morton
2009-01-13 10:51 ` David Howells
2009-01-08 12:54 ` [PATCH 05/10] NOMMU: Make mmap allocation page trimming behaviour configurable. " David Howells
2009-01-08 12:54 ` [PATCH 06/10] NOMMU: Improve procfs output using per-MM VMAs " David Howells
2009-01-08 12:54 ` David Howells [this message]
2009-01-08 12:54 ` [PATCH 08/10] FLAT: Don't attempt to expand the userspace stack to fill the space allocated " David Howells
2009-01-08 12:54 ` [PATCH 09/10] NOMMU: Teach kobjsize() about VMA regions. " David Howells
2009-01-08 12:54 ` [PATCH 10/10] NOMMU: Support XIP on initramfs " David Howells
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=20090108125422.28454.99617.stgit@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bernds_cb1@t-online.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.org \
--cc=torvalds@osdl.org \
--cc=vapier.adi@gmail.com \
/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
all inboxes | Powered by JetHome®