[PATCH v3 0/2] Start removing X86_X32_ABI

[PATCH v3 0/2] Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

Patch #2 prepares the removal of the X32 ABI and has the broader
reasoning. Patch #1 removes x32 from the selftests because it does not
have a depends on and assumes x32 to be always available on x64 and so
it breaks.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
v2…v3: https://patch.msgid.link/20260707212252.bYk3-AlU@linutronix.de
  - added a nolibc-selftests patch to not break it in their setup since
    it does not depend on the symbol.

v1…v2: https://lore.kernel.org/r/20260523093734.A3AR7reJ@linutronix.de
  - reworded commit message

Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Bill Wendling <morbo@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
Cc: Justin Stitt <justinstitt@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Neal Gompa <neal@gompa.dev>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>                                                                                           
Cc: Sam James <sam@gentoo.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Tomas Glozar <tglozar@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: x86@kernel.org
To: linux-kernel@vger.kernel.org
To: linux-kselftest@vger.kernel.org

---
Sebastian Andrzej Siewior (1):
      x86: Start removing X86_X32_ABI

Thomas Weißschuh (1):
      selftests/nolibc: remove the x32 testcase

 arch/x86/Kconfig                               | 14 --------------
 tools/testing/selftests/nolibc/Makefile.nolibc |  6 ------
 tools/testing/selftests/nolibc/run-tests.sh    |  7 +------
 3 files changed, 1 insertion(+), 26 deletions(-)
---
base-commit: 2ee859ebf156157609f71060ae472711c8cbc326
change-id: 20260706-x32_removal-28823498c4a2

Best regards,
--  
Sebastian Andrzej Siewior <bigeasy@linutronix.de>

[PATCH v3 1/2] selftests/nolibc: remove the x32 testcase

[Sebastian Andrzej Siewior]

From: Thomas Weißschuh <linux@weissschuh.net>

Support for the x32 ABI is about to be removed from the kernel itself.
This will break the nolibc x32 testcase.

Remove the testcase to avoid breaking the testsuite in general.

This also ends official support from nolibc proper for x32. But as there
is no clear x32-specific code in the nolibc codebase, there won't be a
removal patch for that.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 tools/testing/selftests/nolibc/Makefile.nolibc | 6 ------
 tools/testing/selftests/nolibc/run-tests.sh    | 7 +------
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/tools/testing/selftests/nolibc/Makefile.nolibc b/tools/testing/selftests/nolibc/Makefile.nolibc
index 06f881e2e90c3..dadde26b9d3bf 100644
--- a/tools/testing/selftests/nolibc/Makefile.nolibc
+++ b/tools/testing/selftests/nolibc/Makefile.nolibc
@@ -47,7 +47,6 @@ XARCH_riscv      = riscv64
 XARCH            = $(or $(XARCH_$(ARCH)),$(ARCH))
 
 # map from user input variants to their kernel supported architectures
-ARCH_x32         = x86
 ARCH_armthumb    = arm
 ARCH_ppc         = powerpc
 ARCH_ppc64       = powerpc
@@ -70,7 +69,6 @@ ARCH            := $(or $(ARCH_$(XARCH)),$(XARCH))
 # kernel image names by architecture
 IMAGE_i386       = arch/x86/boot/bzImage
 IMAGE_x86_64     = arch/x86/boot/bzImage
-IMAGE_x32        = arch/x86/boot/bzImage
 IMAGE_x86        = arch/x86/boot/bzImage
 IMAGE_arm64      = arch/arm64/boot/Image
 IMAGE_arm        = arch/arm/boot/zImage
@@ -106,7 +104,6 @@ DEFCONFIG_sh4        = rts7751r2dplus_defconfig
 DEFCONFIG_openrisc   = virt_defconfig
 DEFCONFIG            = $(or $(DEFCONFIG_$(XARCH)),defconfig)
 
-EXTRACONFIG_x32       = -e CONFIG_X86_X32_ABI
 EXTRACONFIG_arm       = -e CONFIG_NAMESPACES
 EXTRACONFIG_armthumb  = -e CONFIG_NAMESPACES
 EXTRACONFIG_sparc32   = -e CONFIG_TMPFS
@@ -118,7 +115,6 @@ EXTRACONFIG           = $(EXTRACONFIG_$(XARCH))
 TEST =
 
 # QEMU_ARCH: arch names used by qemu
-QEMU_ARCH_x32        = x86_64
 QEMU_ARCH_x86        = x86_64
 QEMU_ARCH_arm64      = aarch64
 QEMU_ARCH_armthumb   = arm
@@ -150,7 +146,6 @@ endif
 # QEMU_ARGS : some arch-specific args to pass to qemu
 QEMU_ARGS_i386       = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_x86_64     = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
-QEMU_ARGS_x32        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_x86        = -M pc -append "console=ttyS0,9600 i8042.noaux panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_arm64      = -M virt -cpu cortex-a53 -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
 QEMU_ARGS_arm        = -M virt -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
@@ -187,7 +182,6 @@ Q=@
 endif
 
 CFLAGS_i386 = $(call cc-option,-m32)
-CFLAGS_x32 = -mx32
 CFLAGS_arm = -marm
 CFLAGS_armthumb = -mthumb -march=armv6t2
 CFLAGS_parisc32 = -mfast-indirect-calls
diff --git a/tools/testing/selftests/nolibc/run-tests.sh b/tools/testing/selftests/nolibc/run-tests.sh
index 6460e25001de8..78d59d9e4a8aa 100755
--- a/tools/testing/selftests/nolibc/run-tests.sh
+++ b/tools/testing/selftests/nolibc/run-tests.sh
@@ -18,7 +18,7 @@ test_mode=system
 werror=1
 llvm=
 all_archs=(
-	i386 x86_64 x32
+	i386 x86_64
 	arm64 arm armthumb
 	mips32le mips32be mipsn32le mipsn32be mips64le mips64be
 	openrisc
@@ -118,7 +118,6 @@ crosstool_arch() {
 	mips*) echo mips;;
 	s390*) echo s390;;
 	sparc*) echo sparc64;;
-	x32*) echo x86_64;;
 	parisc32) echo hppa;;
 	*) echo "$1";;
 	esac
@@ -197,10 +196,6 @@ test_arch() {
 		echo "Unsupported configuration"
 		return
 	fi
-	if [ "$arch" = "x32" ] && [ "$test_mode" = "user" ]; then
-		echo "Unsupported configuration"
-		return
-	fi
 
 	mkdir -p "$build_dir"
 	swallow_output "${MAKE[@]}" defconfig

-- 
2.55.0

[PATCH v3 2/2] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

The x32 ABI was introduced in v3.4 to leverage the additional registers
which were available on x86_64 but not on i386 while keeping the smaller
32bit pointers.

This did not take off. The memory usage usually knows no limit and the
better performance did not reach a point where certain workloads widely
move to x32 and use it exclusively. In the meantime Debian introduced a
patch to disable x32 by default (so it has to be enabled at boot time on
the command line) because they are afraid of the increased attack
surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
rpm in rawhide).

The syscall range >512 used by x32 can not be reused because on earlier
kernels (before v5.4 with x32 enabled, see commit 6365b842aae4
("x86/syscalls: Split the x32 syscalls into their own table") it is not
obvious if the syscall is for x86-64 and not implemented or meant for
x32.
What can be removed are the special compat cases due to different
alignment.

Since there is practically no real use for x32, start removing it by
removing the symbol first, not allowing to enable it. Should nothing
happening by the end of the year, it will removed after the last LTS
kernel this year.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/x86/Kconfig | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bdad90f210e4b..f6fe55fdc928a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3097,20 +3097,6 @@ config IA32_EMULATION_DEFAULT_DISABLED
 	  processes and access to 32-bit syscalls. If unsure, leave it to its
 	  default value.
 
-config X86_X32_ABI
-	bool "x32 ABI for 64-bit mode"
-	depends on X86_64
-	# llvm-objcopy does not convert x86_64 .note.gnu.property or
-	# compressed debug sections to x86_x32 properly:
-	# https://github.com/ClangBuiltLinux/linux/issues/514
-	# https://github.com/ClangBuiltLinux/linux/issues/1141
-	depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
-	help
-	  Include code to run binaries for the x32 native 32-bit ABI
-	  for 64-bit processors.  An x32 process gets access to the
-	  full 64-bit register file and wide data path while leaving
-	  pointers at 32 bits for smaller memory footprint.
-
 config COMPAT_32
 	def_bool y
 	depends on IA32_EMULATION || X86_32

-- 
2.55.0

Re: [PATCH v3 2/2] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz]

Hi Sebastian,

On Thu, 2026-08-13 at 13:04 +0200, Sebastian Andrzej Siewior wrote:
> Since there is practically no real use for x32, start removing it by
> removing the symbol first, not allowing to enable it. Should nothing
> happening by the end of the year, it will removed after the last LTS
> kernel this year.

Wouldn't that mean that x32 won't be usable in the upcoming LTS kernel
then? Why not do it the same way it was done for ia64, wait for the next
LTS release, then remove it.

Anyone still wishing to use it could just install that particular LTS
kernel.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v3 2/2] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-08-13 13:07:53 [+0200], John Paul Adrian Glaubitz wrote:
> Hi Sebastian,
Hi Adrian,

> On Thu, 2026-08-13 at 13:04 +0200, Sebastian Andrzej Siewior wrote:
> > Since there is practically no real use for x32, start removing it by
> > removing the symbol first, not allowing to enable it. Should nothing
> > happening by the end of the year, it will removed after the last LTS
> > kernel this year.
> 
> Wouldn't that mean that x32 won't be usable in the upcoming LTS kernel
> then? Why not do it the same way it was done for ia64, wait for the next
> LTS release, then remove it.

The idea is to revert the (two) commit(s).

> Anyone still wishing to use it could just install that particular LTS
> kernel.
> 
> Adrian

Sebastian

Re: [PATCH v3 2/2] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz]

Hi Sebastian,

On Thu, 2026-08-13 at 14:11 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-13 13:07:53 [+0200], John Paul Adrian Glaubitz wrote:
> > Hi Sebastian,
> Hi Adrian,
> 
> > On Thu, 2026-08-13 at 13:04 +0200, Sebastian Andrzej Siewior wrote:
> > > Since there is practically no real use for x32, start removing it by
> > > removing the symbol first, not allowing to enable it. Should nothing
> > > happening by the end of the year, it will removed after the last LTS
> > > kernel this year.
> > 
> > Wouldn't that mean that x32 won't be usable in the upcoming LTS kernel
> > then? Why not do it the same way it was done for ia64, wait for the next
> > LTS release, then remove it.
> 
> The idea is to revert the (two) commit(s).

But that imply that anyone concerned would have to respond in a timely manner
which is not really something I would expect.

My suggestion would be to leave the complete x32 support fully intact until
the next LTS release so that anyone using that LTS release will know that x32
will be fully working.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v3 2/2] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-08-13 14:24:39 [+0200], John Paul Adrian Glaubitz wrote:
> Hi Sebastian,
Hi Adrian,

> > The idea is to revert the (two) commit(s).
> 
> But that imply that anyone concerned would have to respond in a timely manner
> which is not really something I would expect.

What do you mean by respond in a timely manner?

> My suggestion would be to leave the complete x32 support fully intact until
> the next LTS release so that anyone using that LTS release will know that x32
> will be fully working.

Given the media covered it well, it might work.

> Adrian

Sebastian

Re: [PATCH v3 2/2] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz]

Hi Sebastian,

On Thu, 2026-08-13 at 15:41 +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-13 14:24:39 [+0200], John Paul Adrian Glaubitz wrote:
> > Hi Sebastian,
> Hi Adrian,
> 
> > > The idea is to revert the (two) commit(s).
> > 
> > But that imply that anyone concerned would have to respond in a timely manner
> > which is not really something I would expect.
> 
> What do you mean by respond in a timely manner?

Well, the problem of many kernel maintainers is that they somehow assume that 99%
of the Linux users are present on the Linux kernel mailing list and reading what's
happening there.

Then a kernel developers send a patch introducing a major breaking change, ask for
feedback and then just implement the change because they didn't get any feedback.

However, most users are not reading the LKML, so introducing such breaking changes
in steps hoping for feedback will not work.

My recommendation is therefore to keep everything in a working state until the next
LTS release, then drop everything at once. This way users know that they can stick
for the latest LTS release for the time being to continue to use such a major feature.

> > My suggestion would be to leave the complete x32 support fully intact until
> > the next LTS release so that anyone using that LTS release will know that x32
> > will be fully working.
> 
> Given the media covered it well, it might work.

Most users probably don't even read the media coverage and only realize that a feature
is gone when they try to upgrade their machines and realize the feature has suddenly
vanished.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913