[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

arm64 pointer tagging, VA-bits, the end of the world...



Hi all,

(Sent to cross-distro with debian-arm on cc.)

We have an 'interesting' situation ahead of us, or indeed some of us
have already fallen into it:

ARM64 platforms with > 512GB between the lowest and highest RAM
addresses end up getting their amount of usable memory truncated if
the kernel is built for 39-bit VA (which is what currently happens for
Debian kernels). For 4.7, the arm64 defconfig was changed to enable
48-bit VA by default.

While itself not a critical error (but really annoying), in
combination with GRUB putting the initrd near the top of available
RAM, we end up with systems not booting. We think we've also seen
issues with ACPI tables above this waterline.

Simple - all we need to do then is enable 48-bit VA in the arm64
kernel config? Well, yes. I know Fedora are already doing this, and I
have raised a bug[1] for Debian to do the same.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834505

The problem is - some pieces of software have had time to be written
in a ... let's charitably call it a "focused on amd64" fasion ... with
the embedded assumption that anything above virtual address bit 44 is
a pointer-tag free-for-all.

On the Debian-ish side, we're coming up on both Ubuntu 16.10 and the
freeze for Stretch, leaving a pretty short window to resolve this
unholy kernel->initrd->userland triangle.

The applications we know are affected are luajit and mozjs (libv8 is
not a problem). But this has a follow-on cost: both of these are used
by other packages. Other jit/runtime packages could have their own
issues.

The mozjs bug is fixed on trunk, and will hopefully make it into
release 49[2], but it remains to be seen if that's too late for some
distributions.

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1143022

For luajit, I'm told this has been fixed on 2.1 branch, but not merged
to master?

Now, Jeremy (cc:d) tells me the list of currently-known Fedora
packages affected by this are:
couchdb
elinks
erlang-js
freewrl
libEAI
libproxy-mozjs
mediatomb
pacrunner
plowshare
polkit
cinnamon
cjs
cjs
cjs-tests
gjs
gjs
gjs-tests
gnome-shell
0ad
mongodb
mongodb-server

Some of these may only need an updated luajit/mozjs package, but some
may need more invasive changes.

Anyway, this is just a heads up - anyone sitting on more information
than I've put into this email is very welcome to share it.

/
    Leif


Reply to: