64-bit ARM: our OBS packages

As uncovered in #593 (closed), there are still some issues. We'll most likely first fix them in our OBS packages and then try to fix in official Debian. This ticket shall track the progress.

For now I did some quick experiments on our big aarch64 box, with Debian 10 inside Docker.

Lua packages

• lua-cqueues

  Experiment: I took our OBS version and just added -DCQS_USE_47BIT_LIGHTUSERDATA_HACK=1 into maintainer cflags in debian/rules (maybe a better place can be found). After that it seemed fixed.

• lua-luaossl

  The version in our OBS is too old (20190612). The 64-bit hack was added in 20190731, and after adding -DLUAOSSL_USE_47BIT_LIGHTUSERDATA_HACK=1 the same way it appears fixed. (A newer version exists, but for now I just wanted a quick test, only the necessary tiny changes in debian/.)

• lua-lpeg

  The latest version 1.0.2 apparently can't work with >= 48-bit VA under luajit. When using https fetch (e.g. preffil module in kresd), lpeg crashes at lptree.c:1305 when pushing a C stack pointer as light userdata.

  We found no git or bugtracker for the project. Whole lpeg code has only two occurrences of lua_pushlightuserdata(), so there's a chance that some hack-fix wouldn't be too hard (e.g. masking like in cqueues and luaossl).

Notes on useful stuff

... utilized during these experiments.

• OBS link: https://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10/

• getting backtraces: Debian has no -dbgsym for arm64, but source builds do create them, so that that's what I used. Then start with breakpoint on function lj_err_msg. In some cases it may suffice to just load the module: gdb --args luajit -l cqueues -e 'os.exit(0)'; in others we need to run kresd with config that will use the problematic modules.

• build: save the _orig tarball, also have unpacked sources subdirectory in that place (including debian/). Then run debuild in that subdir, getting *.deb in the parent, installable with dpkg -i foo.deb. Dependencies: apt-get build-dep lua-cqueues, apt install devscripts.

For quick reference, (expected) differences among distros:

• Those that build lua packages directly against luajit (and not against vanilla lua 5.1) don't need the _HACK defines to trigger the hacks.
• Distros (systems?) apparently differ in the way the place memory. Pointers to C stack seem always bad (on 64-bit ARM with >= 48-bit VA kernel). On the other hand, e.g. static variable defined in a C function was OK on some of those and (became?) bad on others, as discovered in !1033 (merged).

Any chance to publish in luarocks.org the fork of any of these projects in case the patches can't be upstreamed?

I'm currently building Knot Resolver in a Docker image and the dependencies are installed from luarocks.org.

First of all we are not jumping to the problem yet so it is premature to think about forking.

Let me turn the question back to you: @hectorm Are you willing to contribute patches to upstream projects/packages?

Unfortunately I don't have the experience to contribute those patches, so I'm just expressing my wishes, but in no way demanding anything. I was just asking to know your intention in case a fork was needed to make the right decisions on my project.

Except for lua-lpeg, I believe the changes will be limited to the debian/ subdirectory so in those cases it doesn't make sense to me to use luarocks to publish the changes.

assigned to @jruzicka

I'd prefer to get more familiar with packaging flow/setups first before tackling this issue that seems to require extensive testing on ARM machine and a code dive into lua-lpeg.

Forking is a last resort option but if really needed, I'll take care of the luarocks.org upload.

In case this blocks or becomes high priority, please let me know and I'll have a look ASAP.

@jruzicka No worries, it certainly is not top priority. LuaJIT is broken on ARM64 since forever.

So, now the preferred way to solve all these will probably be to simply add git version of LuaJIT to our OBS for arm64 Debian, as older Debian versions surely won't get the fix from default repos.

Well, the lua-lpeg problem will most likely happen on all distros, so we might consider doing the same also for others (unless they plan to fix it themselves). LuaJIT hasn't made a release for quite some time, so the update may not get everywhere anytime soon.

added packaging label

assigned to @vcunat and unassigned @jruzicka

unassigned @vcunat

Oh, this ticket remained forgotten. Anyway, LuaJIT added workaround for all these issues, so after years I consider it up to distros to provide a working version.

closed