Hi all,
Can anyone take a look?
We allocate LuaJIT object within 47-bit, but light user data comes from
other C code which is allocated outside LuaJIT.
This issue makes some applications unusable on ARM platforms with 48-bit VA
kernel configuration, such as wrk and openresty.
Regards,
Zheng
*From:* luajit-bounce@xxxxxxxxxxxxx [mailto:luajit-bounce@xxxxxxxxxxxxx] *On
Behalf Of *Zhongwei Yao
*Sent:* 19 October 2016 09:47
*To:* luajit@xxxxxxxxxxxxx
*Subject:* fix lightud type for 48-bit virtual address
Hi, all,
LuaJIT may crash when system use 48-bit virtual address. linux on ARM64 is
one of such cases. Following test is an example:
https://github.com/LuaJIT/LuaJIT-test-cleanup/blob/
master/test/misc/catch_wrap.lua
It is caused by type value overriding the 48 bit of light user data
(lightud).
This patch try to fix this issue on ARM64 platform. Could you please take a
review, thanks! Here is my pull request:
https://github.com/LuaJIT/LuaJIT/pull/230
Here are some details:
LauJIT uses 4 bits for encoding type value in NAN internally. For now, we
have 14 different types internally (ORDER LJ_T, refers more in lj_obj.h).
It needs 4 bits at least to encode. And there are only 4 bits available in
NAN for our encoding:
------MSW------.------LSW------
|1..1|itype|1..................1|
So shift one bit towarding to MSW is not doable here.
I try to fix it by setting 2 type values (~3 and ~4) to LJ_TLIGHTUD, which
enables encode the 48 bit of address in lightud type itself. Setting it to
~3 and ~4 maintains current ORDER LJ_T and introduce less changes compared
with other solutions. E.g. merging LJ_TFALSE and LJ_TTRUE into one type
like LJ_TBOOL and set LJ_TLIGHTUD to ~2 and ~3; or replace lightud type
values with ~13 and ~14 and shift other type values by one. This idea is
inspired by the discussion in https://github.com/LuaJIT/LuaJIT/issues/49 ;.
--
Best regards,
Zhongwei
