From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87EFE3D170B for ; Tue, 2 Jun 2026 09:48:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780393692; cv=none; b=nCL/ZZaiQA1xacpMn1jG2jFINlYDOGbLinMdvkCyisryzqbba4lQ4CajDSgsSnVXbaFtLs6ZODzettSdyeUwHaq8B4Fg2x1y3PnUXh9z4FNVD4azSFNSoa9UkUKNK+9atQ2iJoYTecfhJqF7PtKGs9ROoWjO5DkhNYiX/Zx6HPY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780393692; c=relaxed/simple; bh=2eY3YjJXdLytz2jRPP89G6wafuZk4v1O9i9Onubfo+o=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=hSNgfMkvvJ9l3wRg98Akhca52t83jm2ha9Y/vqjor+v6IKn1kqmZMC1cGvtTE9ox9Pz+mnYDnfN1MglkfdmNr2sb793X/cgQSJ43UuGMw//CRiE9iDZjtgIYSXmISGaRKY8udwG4QDILmEBlIiLrZ5D+pPvEyZQcwouR+XmVvME= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=R1eNQQ2v; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="R1eNQQ2v" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-4600cbb06deso1318219f8f.1 for ; Tue, 02 Jun 2026 02:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1780393689; x=1780998489; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=usTbRr0yRBpJ5q18d4YvFKcKqam/9vB3dzryhGsuIpw=; b=R1eNQQ2vMspnL37OoRbCxInn73wpZzs8lRYZsKfNCJiaLwICSHll7DbfiMgKXuDudQ aT8yum1tr8CX8B7sQRoPA3p+dmbxXYEWV1nBD5L6a08Ru5M3i0tWLzk5YYLiI5M8iZCx gZjln75wUOP07cYYlTC17MrgumkM+fOTUB38E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780393689; x=1780998489; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=usTbRr0yRBpJ5q18d4YvFKcKqam/9vB3dzryhGsuIpw=; b=LJvTeuk5kSoqsLTNxQ3YNQX2vLJYraFimN9PSPYbfgRehJsD+s8rIR00zGzgbxtXMk E7VboENe70Thtfn+t7WLnsU32IpMfL4v6KFFmY44A9r26u/DVZKl8MqTsSkNsE3txzXd PLVdHZ+vsWEBlkU8bX/pUM0m4QnMtAs1GP37uTWE070Xhmwdjo/DbIioq0hx8d1JwT6h 2dzx4Vic1CNrjxlMP1w33HJSG3ez/4gfbqOlWNrAuY86fidCge3QejAm1tYR7u4RI5Uo 4+8Y6/0rw3tm4Krvesz1K62rU8kB85hfpf2Fzns2AtLFy6JC4wticEGfprJ5oIKBiyO3 uXjg== X-Forwarded-Encrypted: i=1; AFNElJ8LiPpksQbjMqNT5BOtkzTBItzwWJzj2snX4Q6/04U6qNAbPaWw1OUlc21KQiJm4EV4DCb2oasO2pSuvI4=@vger.kernel.org X-Gm-Message-State: AOJu0YyWVMlJ7wqu5MAGrC+IR2vbZIy06wh7tTjbkXkJpII8MgJUIrg0 biKrtqQL1I5a+PVlS291IT65PShWq/B1bBej9rXCXSoApZYH5fv3nmLLHFqPW7fdeiw= X-Gm-Gg: Acq92OGciJrmUcIVIDfSRVSmZAXqyVCyPJizex5UxUi2mspPUfuqH4JGP/L+gEj/U8f gZuTUCPz5N5bp3ZQ282essb7UYZSPXEGUR3b2lf3c/KHqJdHDLEuoF9Y9UzDeLVGwoyDyoaQDOR EzPGmndTIIDdpNVutyjja5BmimgYE5ChXQs/aHCxOJ3BNGPnfCUrJYda8Tqrh2YdzFtTT5Vowan ShRin3ntBiv2PZyG2nSSgKPVaQ6y4KYqVnyM/JprWpjUeS59aLNjsk8wHKSv7srrndvocj+l43D mzeUU6glYGGqEZGeaCPNLTd20PiA68fNUjZNS2o/Bz254idwAwt9r4YTpEGWXz5PpWMrloddX1X o/tdrsQxRa0oPzF76sGWA1UTFxwg4LQ6CYR2/NMJqlyvMY2OqSX4Q0+/yQY2hUSrb54BHqAeFXL emVh8dz5+BebdTz3+zOBKsoy2u03528XW4bGOV6/tjA2WARthv+4etLL6HokMWqJyVE6fTczS3V 7n8QALlx73gvzh0nKDg063mQ9I= X-Received: by 2002:adf:e307:0:b0:450:ad00:86aa with SMTP id ffacd0b85a97d-46018d3da9emr3622094f8f.15.1780393688793; Tue, 02 Jun 2026 02:48:08 -0700 (PDT) Received: from ?IPv6:2001:8b0:aba:5f3c:60b8:c7e8:3832:2c23? ([2001:8b0:aba:5f3c:60b8:c7e8:3832:2c23]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ef354bb62sm30563317f8f.19.2026.06.02.02.48.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 02:48:08 -0700 (PDT) Message-ID: <5555688abbf67fb0a2615afd3188d3f9c075577b.camel@linuxfoundation.org> Subject: Re: [PATCH] x86: Start removing X86_X32_ABI From: Richard Purdie To: Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, x86@kernel.org Cc: "H. Peter Anvin" , Borislav Petkov , Dave Hansen , Ingo Molnar , Jonathan Corbet , Thomas Gleixner Date: Tue, 02 Jun 2026 10:48:07 +0100 In-Reply-To: <20260523093734.A3AR7reJ@linutronix.de> References: <20260523093734.A3AR7reJ@linutronix.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-9 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2026-05-23 at 11:37 +0200, Sebastian Andrzej Siewior wrote: > 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. >=20 > 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). >=20 > The last syscall for x86_64 is currently at 471. The first x32 starts at > 512 which leaves 40 new syscalls in between. Without the x32 ABI, those > syscalls could be used since x32 wouldn't be an option and therefore > reserved. >=20 > 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 within the next half year, lets remove code bits around August > after the summer break. >=20 > Signed-off-by: Sebastian Andrzej Siewior > --- > =C2=A0arch/x86/Kconfig | 14 -------------- > =C2=A01 file changed, 14 deletions(-) >=20 > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index f3f7cb01d69d0..2b246a6125768 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -3143,20 +3143,6 @@ config IA32_EMULATION_DEFAULT_DISABLED > =C2=A0 =C2=A0 processes and access to 32-bit syscalls. If unsure, leave i= t to its > =C2=A0 =C2=A0 default value. > =C2=A0 > -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 > - =C2=A0 Include code to run binaries for the x32 native 32-bit ABI > - =C2=A0 for 64-bit processors.=C2=A0 An x32 process gets access to the > - =C2=A0 full 64-bit register file and wide data path while leaving > - =C2=A0 pointers at 32 bits for smaller memory footprint. > - > =C2=A0config COMPAT_32 > =C2=A0 def_bool y > =C2=A0 depends on IA32_EMULATION || X86_32 FWIW we (as in the Yocto Project) have been supporting x32 for a long time so we regularly build/boot/test this as part of our CI (toolchain + kernel + userspace). That does mean we end up sending patches when things break. We did reduce the scope of the userspace we test a few years ago to try and keep things manageable. We struggle (as most do) to know who uses what, nobody tells us when it works. My instincts say it isn't actively used and if the kernel drops it, we would follow. I don't have any strong objection at this point. I mention it mainly to explain why you might see patches from us. Cheers, Richard