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 596B314020D4; Thu, 12 Jun 2025 12:36:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 596B314020D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1749721009; bh=2n0ArOuwABrMi/qb+XeasDbeocu6iPYyRxqjS1FEcKg=; h=To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=XhafqzX6gPfz6s0fSZLEBmw7HHX4HIo4pkuJEgd4iYf3OCScJbX5W1vm2LPKhrEdW vRIOQqYhhc4+34Et3EmTZvUA8Ej59ktilxcCZ21ixgdgHdh3TeRlNCkRRqHLe63yjd RSkL1j+XMLXIOR73ZcCtzZJeaJ/QhaOv8znVwUEg= Received: from send105.i.mail.ru (send105.i.mail.ru [89.221.237.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id EE7BB14020D7 for ; Thu, 12 Jun 2025 12:36:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EE7BB14020D7 Received: by exim-smtp-85b97957d7-ws8sf with esmtpa (envelope-from ) id 1uPeMZ-00000000EuQ-0AXo; Thu, 12 Jun 2025 12:36:47 +0300 To: Sergey Bronnikov Date: Thu, 12 Jun 2025 12:36:51 +0300 Message-ID: <20250612093651.7552-1-skaplun@tarantool.org> X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailru-Src: smtp X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD909B82214CC988917A32B43B0EB0E75F6640CCDCE6065B3A900894C459B0CD1B9FC5B24C261F6652503ED270C30F246C500660140C20DE9BC5715A29F2CB2652B2A808E2AF9A6ECDE X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7BAE5222749FC9020C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6759CC434672EE6371C2A783ECEC0211ADC4224003CC836476D5A39DEEDB180909611E41BBFE2FEB2B7B35ABFCA173818D89D85A49733695D562D75793834A2B2AC1A59496E8A6AAF89FA2833FD35BB23D9E625A9149C048EE1E561CDFBCA1751FE5D25F19253116ADD2E47CDBA5A96583BD4B6F7A4D31EC0BC014FD901B82EE079FA2833FD35BB23D27C277FBC8AE2E8B5FC25ED3FCEC3375A471835C12D1D977C4224003CC8364762BB6847A3DEAEFB0F43C7A68FF6260569E8FC8737B5C2249EC8D19AE6D49635B68655334FD4449CB9ECD01F8117BC8BEAAAE862A0553A39223F8577A6DFFEA7CB0EC3B1FCAE4A06943847C11F186F3C59DAA53EE0834AAEE X-C1DE0DAB: 0D63561A33F958A52E6442317AA6908F5002B1117B3ED696B562B4A8E31BE6E09E040399BDE4761E823CB91A9FED034534781492E4B8EEAD528DE7AA5F2BD788C79554A2A72441328621D336A7BC284946AD531847A6065A17B107DEF921CE79BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742DC8270968E61249B1004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D340297C696F996E3840630E54B7E894700B5F6BE643C5DF8727D3D6AFEB0EE3ABEEAC0BBF467751ADF1D7E09C32AA3244C9B01022352F96B1E77DD89D51EBB77421A38E7EE902134F0EA455F16B58544A2557BDE0DD54B3590A5AE236DF995FB59829709634694AABAED6A17656DB59BCAD427812AF56FC65B X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu53w8ahmwBjZKM/YPHZyZHvz5uv+WouB9+ObcCpyrx6l7KImUglyhkEat/+ysWwi0gdhEs0JGjl6ggRWTy1haxBpVdbIX1nthFXMZebaIdHP2ghjoIc/363UZI6Kf1ptIMVSykAyseJQ6/OSi6iMGkSEk= X-DA7885C5: E6E3E22D3F124672F255D290C0D534F9C61C268E6CC66B060EAEDD643C8F173EDC72811A6B5E1EC15B1A4C17EAA7BC4BEF2421ABFA55128DAF83EF9164C44C7E X-Mailru-Sender: 689FA8AB762F7393FE9E42A757851DB625C250BAD425B0E30C1E5D516D2D668E861BD5F7C1DE7455E49D44BB4BD9522A059A1ED8796F048DB274557F927329BE89D5A3BC2B10C37545BD1C3CC395C826B4A721A3011E896F X-Mras: Ok Subject: [Tarantool-patches] [PATCH luajit] ARM64: Fix assembly of HREFK. 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 Reported by caohongqing. Fix contributed by Peter Cawley. (cherry picked from commit 8fbd576fb9414a5fa70dfa6069733d3416a78269) `asm_hrefk()` uses the check for the offset for the corresponding node structure. However, the target load is performed from its inner `key` field with the offset 8. In the case of a huge table, it is possible that the offset of the node (4095 * 8) is less than 4096 * 8 and can be emitted via the corresponding instruction as an immediate offset, but the offset of the `key` field is not. This leads to the corresponding assertion failure in `emit_lso()`. This patch fixes this behaviour by the correct check. Sergey Kaplun: * added the description and the test for the problem Part of tarantool/tarantool#11278 --- Related issues: * https://github.com/LuaJIT/LuaJIT/issues/1026 * https://github.com/tarantool/tarantool/issues/11278 Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1026-arm64-invalid-hrefk-offset-check src/lj_asm_arm64.h | 2 +- ...-arm64-invalid-hrefk-offset-check.test.lua | 48 +++++++++++++++++++ 2 files changed, 49 insertions(+), 1 deletion(-) create mode 100644 test/tarantool-tests/lj-1026-arm64-invalid-hrefk-offset-check.test.lua diff --git a/src/lj_asm_arm64.h b/src/lj_asm_arm64.h index 6c7b011f..a7f059a2 100644 --- a/src/lj_asm_arm64.h +++ b/src/lj_asm_arm64.h @@ -885,7 +885,7 @@ static void asm_hrefk(ASMState *as, IRIns *ir) IRIns *irkey = IR(kslot->op1); int32_t ofs = (int32_t)(kslot->op2 * sizeof(Node)); int32_t kofs = ofs + (int32_t)offsetof(Node, key); - int bigofs = !emit_checkofs(A64I_LDRx, ofs); + int bigofs = !emit_checkofs(A64I_LDRx, kofs); Reg dest = (ra_used(ir) || bigofs) ? ra_dest(as, ir, RSET_GPR) : RID_NONE; Reg node = ra_alloc1(as, ir->op1, RSET_GPR); Reg key, idx = node; diff --git a/test/tarantool-tests/lj-1026-arm64-invalid-hrefk-offset-check.test.lua b/test/tarantool-tests/lj-1026-arm64-invalid-hrefk-offset-check.test.lua new file mode 100644 index 00000000..de243814 --- /dev/null +++ b/test/tarantool-tests/lj-1026-arm64-invalid-hrefk-offset-check.test.lua @@ -0,0 +1,48 @@ +local tap = require('tap') + +-- Test file to demonstrate LuaJIT misbehaviour when assembling +-- HREFK instruction on arm64 with the huge offset. +-- See also: https://github.com/LuaJIT/LuaJIT/issues/1026. +local test = tap.test('lj-1026-arm64-invalid-hrefk-offset-check'):skipcond({ + ['Test requires JIT enabled'] = not jit.status(), +}) + +test:plan(1) + +-- The assertion fails since in HREFK we are checking the offset +-- from the hslots of the table of the Node structure itself +-- instead of its inner field `key` (with additional 8 bytes). +-- So to test this, we generate a big table with constant keys +-- and compile a trace for each HREFK possible. + +local big_tab = {} +-- The map of the characters to generate constant string keys. +-- The offset of the node should be 4096 * 8. It takes at least +-- 1365 keys to hit this value. The maximum possible slots in the +-- hash part is 2048, so to fill it with the maximum density (with +-- the way below), we need 45 * 45 = 2025 keys. +local chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRS' +for c1 in chars:gmatch('.') do + for c2 in chars:gmatch('.') do + big_tab[c1 .. c2] = 1 + end +end + +jit.opt.start('hotloop=1') + +-- Generate bunch of traces. +for c1 in chars:gmatch('.') do + for c2 in chars:gmatch('.') do + loadstring([=[ + local t = ... + for i = 1, 4 do + -- HREFK generation. + t[ ']=] .. c1 .. c2 .. [=[' ] = i + end + ]=])(big_tab) + end +end + +test:ok(true, 'no assertion failed') + +test:done(true) -- 2.49.0