From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id AD8416EC40; Tue, 6 Jul 2021 20:42:17 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org AD8416EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1625593337; bh=YuIvDAkQW248F0yp0bJQSP8vn7fRpLW9PDXQo+zXhXI=; h=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=lGY3xFK/OeCnFAgcg8cZ7vyHwAVpLlXJGjxuVp6HM2CW6ZAqggFS11LcUetpAUl/6 gilSM2MfPUIeEp6MoXNatKJYehj6YcxENRhLK1VREEknb6dv1xfoEwQ4fQt13c6vvN H2qdoiOwSyWniZRWnpE7yDOpb5tBw6vd2fCEP1NM= Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id ED30C6EC44 for ; Tue, 6 Jul 2021 20:41:17 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org ED30C6EC44 Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1m0p4P-0008Sr-8G; Tue, 06 Jul 2021 20:41:17 +0300 To: Igor Munkin , Sergey Ostanevich Date: Tue, 6 Jul 2021 20:40:06 +0300 Message-Id: X-Mailer: git-send-email 2.31.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD954DFF1DC42D673FB4F75AC5594ACDC16869A51A860A12816182A05F5380850401C4E6D0672212048575442B84AAE074C4BF071C7F0773C2B5AC61F38E3C06A05 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE707FD2F46D4FEEE7FC2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7AA1605287C7F04D6EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38BBCA57AF85F7723F2AA538A0F488E9FC8503EE6B462593C97CC7F00164DA146DAFE8445B8C89999728AA50765F7900637F924B32C592EA89F389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC81D471462564A2E19F6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8B08F9A42B2210255C75ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: C20DE7B7AB408E4181F030C43753B8186998911F362727C414F749A5E30D975C62E2A2CC9B321AEEE12EAD6A3937504E378BF94684FB21389C2B6934AE262D3EE7EAB7254005DCED7532B743992DF240BDC6A1CF3F042BAD6DF99611D93F60EF309DFB797F6729CB699F904B3F4130E343918A1A30D5E7FCCB5012B2E24CD356 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34C1D376EF32BB0896845569068343ABA3F46E554F531B04D1AC20D972212B5CBE90142CCB00EE676A1D7E09C32AA3244C4B900D82DD5F6FB99AE9E0B97290590030363D8B7DA7DD44927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojotfFaHYUgbDxSATmXFFneg== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB458E0E3E53A106A929FB1F8DF31E0898A0A0FD62E7DB478E6F2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes. X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" From: Mike Pall 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