Re: [PATCH] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Mon, Jun 1, 2026, at 23:44, Sebastian Andrzej Siewior wrote:
> On 2026-05-31 23:46:10 [+0200], Arnd Bergmann wrote:
>>
>> 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.

Right, or maybe even more common an embedded system running an
old kernel that a SoC vendor has never updated, but using a recent
musl build.

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

The kernel only sees a 32-bit number, with bit 30 (0x40000000)
set by libc in regular x32 user space, so x32 ioctl() would be
1073742338 (0x40000202). On newer kernels, the bit gets checked
in do_syscall_64() so it has to be cleared for LP64-only
syscalls but set for ILP32-only ones.

Before 6365b842aae4, the bit was just masked out, so it made
no difference for deciding if a syscall was valid and
was only checked in in_x32_syscall().

On syscalls that are the same between the two, the bit has no
practical effect today.

       Arnd