From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Igor Munkin <imun@tarantool.org>, Sergey Ostanevich <sergos@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes. Date: Tue, 6 Jul 2021 20:40:06 +0300 [thread overview] Message-ID: <c04ec11ad17902359194966315cd6cfa81f8bd45.1625587322.git.skaplun@tarantool.org> (raw) In-Reply-To: <cover.1625587322.git.skaplun@tarantool.org> From: Mike Pall <mike> This reduces overall performance on ARM64, but we have no choice. Linux kernel default userspace VA is 48 bit, but we'd need 47 bit. mremap() ignores address hints due to a kernel API issue. The mapping may move to an undesired address which will cause an assert or crash. Reported by Raymond W. Ko. (cherry picked from commit 67dbec82f4f05a416a78a560a726553beaa7a223) 47-bit VA space is required by LuaJIT for keeping a GC object pointer in TValue. When need to reallocate to huge sized block `mrepmap()` on arm64 may move out VA space from the 47-bit range. `mremap()` accepts the fifth argument (new address hint) only with MREMAP_FIXED flag. In that case it unmaps any other mapping to specified address. To avoid this behaviour this patch restricts `mremap()` to relocate the mapping to a new virtual address by reset MREMAP_MAYMOVE flag for arm64 architecture. Sergey Kaplun: * added the description and the test for the problem Needed for tarantool/tarantool#6154 --- src/lj_alloc.c | 2 +- .../lj-671-arm64-assert-after-mremap.test.lua | 24 +++++++++++++++++++ 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua diff --git a/src/lj_alloc.c b/src/lj_alloc.c index 9fc761c7..ffcd019b 100644 --- a/src/lj_alloc.c +++ b/src/lj_alloc.c @@ -378,7 +378,7 @@ static void *CALL_MREMAP_(void *ptr, size_t osz, size_t nsz, int flags) #define CALL_MREMAP(addr, osz, nsz, mv) CALL_MREMAP_((addr), (osz), (nsz), (mv)) #define CALL_MREMAP_NOMOVE 0 #define CALL_MREMAP_MAYMOVE 1 -#if LJ_64 && !LJ_GC64 +#if LJ_64 && (!LJ_GC64 || LJ_TARGET_ARM64) #define CALL_MREMAP_MV CALL_MREMAP_NOMOVE #else #define CALL_MREMAP_MV CALL_MREMAP_MAYMOVE diff --git a/test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua b/test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua new file mode 100644 index 00000000..0be60a2d --- /dev/null +++ b/test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua @@ -0,0 +1,24 @@ +local tap = require('tap') + +-- Test file to demonstrate assertion after `mremap()` on arm64. +-- See also, https://github.com/LuaJIT/LuaJIT/issues/671. + +local test = tap.test('lj-671-arm64-assert-after-mremap') +test:plan(1) + +-- `mremap()` is used on Linux for remap directly mapped big +-- (>=DEFAULT_MMAP_THRESHOLD) memory chunks. +-- The simplest way to test memory move is to allocate the huge +-- memory chunk for string buffer directly and reallocate it +-- after. +-- To allocate buffer exactly to threshold limit for direct chunk +-- mapping use `string.rep()` with length equals threshold. +-- Then concatenate result string (with length of +-- DEFAULT_MMAP_THRESHOLD) with the other one to reallocate +-- and remap string buffer. + +local DEFAULT_MMAP_THRESHOLD = 128 * 1024 +local s = string.rep('x', DEFAULT_MMAP_THRESHOLD)..'x' +test:ok(s) + +os.exit(test:check() and 0 or 1) -- 2.31.0
next prev parent reply other threads:[~2021-07-06 17:42 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-06 17:40 [Tarantool-patches] [PATCH luajit 0/2] arm64: fix 48-bit addresses issues Sergey Kaplun via Tarantool-patches 2021-07-06 17:40 ` [Tarantool-patches] [PATCH luajit 1/2] Add support for full-range 64 bit lightuserdata Sergey Kaplun via Tarantool-patches 2021-07-27 13:59 ` Igor Munkin via Tarantool-patches 2021-07-28 12:29 ` Sergey Kaplun via Tarantool-patches 2021-08-01 10:36 ` Igor Munkin via Tarantool-patches 2021-08-02 14:56 ` Sergey Kaplun via Tarantool-patches 2021-08-01 16:25 ` Sergey Ostanevich via Tarantool-patches 2021-08-02 14:51 ` Sergey Kaplun via Tarantool-patches 2021-08-02 15:42 ` Igor Munkin via Tarantool-patches 2021-08-10 16:46 ` Sergey Ostanevich via Tarantool-patches 2021-08-11 5:54 ` Vitaliia Ioffe via Tarantool-patches 2021-07-06 17:40 ` Sergey Kaplun via Tarantool-patches [this message] 2021-07-27 15:23 ` [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes Igor Munkin via Tarantool-patches 2021-07-28 12:29 ` Sergey Kaplun via Tarantool-patches 2021-08-01 10:36 ` Igor Munkin via Tarantool-patches 2021-08-01 16:59 ` Sergey Ostanevich via Tarantool-patches 2021-08-02 15:08 ` Sergey Kaplun via Tarantool-patches 2021-08-02 15:55 ` Sergey Ostanevich via Tarantool-patches 2021-08-02 15:11 ` Sergey Kaplun via Tarantool-patches 2021-08-11 7:21 ` [Tarantool-patches] [PATCH luajit 0/2] arm64: fix 48-bit addresses issues Igor Munkin via Tarantool-patches
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=c04ec11ad17902359194966315cd6cfa81f8bd45.1625587322.git.skaplun@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=imun@tarantool.org \ --cc=sergos@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes.' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox