Re: [PATCH] x86: Start removing X86_X32_ABI

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, May 26, 2026, at 22:43, Sebastian Andrzej Siewior wrote:
> On 2026-05-26 08:54:56 [-0700], H. Peter Anvin wrote:
>
>> System call numbers or even mechanisms are in no wise tied to the ELF
>> type. An x86-64 binary can issue x86-64, x32 or i386 system calls,
>> even from 64-bit mode!
>
> But *why* have syscalls if nothing else works? It is not that you have a
> natural environment where these things work and in a later kernel they
> behave differently. It just not working.

It's not about having the syscalls, it's whether we need to keep
them as 'reserved' indefinitely, the same way we don't reuse
any other number that ever did something.

The problem is what happens when you run new userspace that calls
a syscall >512 on a kernel before v5.4 with x32 enabled, see commit
6365b842aae4 ("x86/syscalls: Split the x32 syscalls into their own
table").

The normal rule is that any new syscall should return -ENOSYS on
old kernels to make it safe to detect from userspace whether it
is available or not. On linux-5.4 or newer kernels, that is what
happens. On older ones this would call one of the 35 x32 syscalls
that were available at the time. 

Skipping these numbers is clearly annoying, given that we now
synchronize them across all architectures, but it's probably
the right thing to do, at least if C libraries that want to
support future syscalls >511 also want to keep running on old
kernels. glibc still officially supports linux-3.2 (2.6.32
on x86), and musl tries to support even older versions.

      Arnd