Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Sergey Kaplun <skaplun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix assembly of HREFK.
Date: Wed, 25 Jun 2025 17:20:09 +0300	[thread overview]
Message-ID: <ec05ccf7-097d-4987-bc76-cf51207bfb2e@tarantool.org> (raw)
In-Reply-To: <20250612093651.7552-1-skaplun@tarantool.org>

[-- Attachment #1: Type: text/plain, Size: 4488 bytes --]

Hi, Sergey,

thanks for the patch! Please see my comments below.

Sergey

On 6/12/25 12:36, Sergey Kaplun wrote:
> From: Mike Pall <mike>
>
> 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()`.

The issue [1] contains yet another fix in the same place [2]. We decided 
to backport the patch

separately. But please mention this in commit message.


1. https://github.com/LuaJIT/LuaJIT/issues/1026

2. 
https://github.com/LuaJIT/LuaJIT/commit/93ce12ee15abf28ef4cb24ae7e4b8a5b73d75c85


>
> 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(),
It is an ARM-specific patch, should we add a condition for ARM here?
> +})
> +
> +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
s/Node/`Node`/
> +-- 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 inchars:gmatch('.') do
> +  for c2 inchars:gmatch('.') do
> +    big_tab[c1 .. c2] = 1
> +  end
> +end
> +
> +jit.opt.start('hotloop=1')
> +
> +-- Generate bunch of traces.
> +for c1 inchars:gmatch('.') do
> +  for c2 inchars: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')

I would replace testcase description to something like "emitted assembly 
is correct".

Feel free to ignore.

> +
> +test:done(true)

[-- Attachment #2: Type: text/html, Size: 6425 bytes --]

  reply	other threads:[~2025-06-25 14:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12  9:36 Sergey Kaplun via Tarantool-patches
2025-06-25 14:20 ` Sergey Bronnikov via Tarantool-patches [this message]
2025-06-25 14:41   ` Sergey Kaplun via Tarantool-patches
2025-06-26  9:47     ` Sergey Bronnikov via Tarantool-patches
  -- strict thread matches above, loose matches on Subject: below --
2021-10-27 13:02 Sergey Kaplun via Tarantool-patches
2022-03-30 10:26 ` sergos via Tarantool-patches
2022-04-04  8:55   ` Sergey Kaplun via Tarantool-patches
2022-06-29  9:16     ` Igor Munkin via Tarantool-patches
2022-06-30 12:11 ` 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=ec05ccf7-097d-4987-bc76-cf51207bfb2e@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=sergeyb@tarantool.org \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix assembly of HREFK.' \
    /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