Re: [PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-05-31 23:46:10 [+0200], Arnd Bergmann wrote:
> 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").

Okay, that is point. That would be something like new Debian distro but
still the old kernel.

> 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.

I see. That is unfortunate then.

But just to check one thing: From the referenced commit "ioctl() is nr
16 on x86_64 but 514 on x32". So the kernel knows if it is x-64 or x-32?
But we can't reuse 514 on x-64 and return -1 on -x32 simply because the
pre v5.4 kernel do the ioctl() instead of an error?

>       Arnd

Sebastian