• R/O
  • HTTP
  • SSH
  • HTTPS

Commit

Tags
No Tags

Frequently used words (click to add to your profile)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

Commit MetaInfo

Revisión11d3672788b48548811810bdc0f3f7969662572d (tree)
Tiempo2022-01-19 01:44:05
AutorAlex Bennée <alex.bennee@lina...>
CommiterAlex Bennée

Log Message

linux-user: expand reserved brk space for 64bit guests

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>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220113165550.4184455-1-alex.bennee@linaro.org>

Cambiar Resumen

Diferencia incremental

--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2783,11 +2783,17 @@ static void load_elf_image(const char *image_name, int image_fd,
27832783 * and the stack, lest they be placed immediately after
27842784 * the data segment and block allocation from the brk.
27852785 *
2786- * 16MB is chosen as "large enough" without being so large
2787- * as to allow the result to not fit with a 32-bit guest on
2788- * a 32-bit host.
2786+ * 16MB is chosen as "large enough" without being so large as
2787+ * to allow the result to not fit with a 32-bit guest on a
2788+ * 32-bit host. However some 64 bit guests (e.g. s390x)
2789+ * attempt to place their heap further ahead and currently
2790+ * nothing stops them smashing into QEMUs address space.
27892791 */
2792+#if TARGET_LONG_BITS == 64
2793+ info->reserve_brk = 32 * MiB;
2794+#else
27902795 info->reserve_brk = 16 * MiB;
2796+#endif
27912797 hiaddr += info->reserve_brk;
27922798
27932799 if (ehdr->e_type == ET_EXEC) {