From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, thuth@redhat.com, cohuck@redhat.com,
richard.henderson@linaro.org,
"Laurent Vivier" <laurent@vivier.eu>,
qemu-s390x@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>
Subject: [RFC PATCH] linux-user: expand reserved brk space for 64bit guests
Date: Thu, 13 Jan 2022 16:55:50 +0000 [thread overview]
Message-ID: <20220113165550.4184455-1-alex.bennee@linaro.org> (raw)
A recent change to fix commpage allocation issues on 32bit hosts
revealed another intermittent issue on s390x. The root cause was the
headroom we give for the brk space wasn't enough causing the guest to
attempt to map something on top of QEMUs own pages. We do not
currently do anything to protect from this (see #555).
By inspection the brk mmap moves around and top of the address range
has been measured as far as 19Mb away from the top of the binary. As
we chose a smallish number to keep 32bit on 32 bit feasible we only
increase the gap for 64 bit guests. This does mean that 64-on-32
static binaries are more likely to fail to find a hole in the address
space but that is hopefully a fairly rare situation.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
linux-user/elfload.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 64b87d37e8..9628a38361 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2800,11 +2800,17 @@ static void load_elf_image(const char *image_name, int image_fd,
* and the stack, lest they be placed immediately after
* the data segment and block allocation from the brk.
*
- * 16MB is chosen as "large enough" without being so large
- * as to allow the result to not fit with a 32-bit guest on
- * a 32-bit host.
+ * 16MB is chosen as "large enough" without being so large as
+ * to allow the result to not fit with a 32-bit guest on a
+ * 32-bit host. However some 64 bit guests (e.g. s390x)
+ * attempt to place their heap further ahead and currently
+ * nothing stops them smashing into QEMUs address space.
*/
+#if TARGET_LONG_BITS == 64
+ info->reserve_brk = 32 * MiB;
+#else
info->reserve_brk = 16 * MiB;
+#endif
hiaddr += info->reserve_brk;
if (ehdr->e_type == ET_EXEC) {
--
2.30.2
next reply other threads:[~2022-01-13 16:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 16:55 Alex Bennée [this message]
2022-01-18 11:48 ` [RFC PATCH] linux-user: expand reserved brk space for 64bit guests Thomas Huth
2022-01-26 21:46 ` Richard Henderson
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=20220113165550.4184455-1-alex.bennee@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cohuck@redhat.com \
--cc=laurent@vivier.eu \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).