From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FEBB149C7B for ; Sun, 31 May 2026 21:46:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780263996; cv=none; b=BBhaWLLzp6XPYb15/l0Sb5NtxjR/0DHFM7RS/oR9SIBOKZV22uoszBoxgB3MupZAzByGNK02H/44b0koYJwqudAQiV+lNdhzN6s66ASTKbcdsfCrm5ukKRjFlkfVayhzm1q0CKZAbM2N5g+JG/1KEQ8eyhI13tsgbqRxdno5KkE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780263996; c=relaxed/simple; bh=oMIW2KAEesVSsvDbZGjm/xIUhtWqPDaTJsCe+UX8Ols=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=FUs45WFN0SWGtwXHYKNy5SP9frylu9sl4Tkuwnyqcnoo9PR0Jd/QdRFI7/vIMYJ04rZH5lVbN4JDUjH0gx7hBN4hzO6LlkEe/CQOnCIgwUjHhj+zfBMNKOkIoiT8GLRRyet3YHXdM3PmBiWduSKLtubjNNz3HmNvcJTXNuDDupQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=ekX/crc3; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=pp9nZZlG; arc=none smtp.client-ip=202.12.124.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="ekX/crc3"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="pp9nZZlG" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id EB4A51D00024; Sun, 31 May 2026 17:46:32 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Sun, 31 May 2026 17:46:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1780263992; x=1780350392; bh=sloNsprdlXvkjeTtMi/sX+bK1CKK0vU4yLyBSdYlTzU=; b= ekX/crc3G+ac26Pwoz23z1xlGhbDE04N/2hH4x1/MwmRnvhbAO70Pqs15a6Z4Cvg SZDgn07/QF5rYDTYJ4S5rRpH1WMunaAjPQaWG3argNYcaXLoUAKrnTWXvyG12rhE auGwNvZZtnNuH51qePewtDTKvkwX7tvT3YakAX6jJhRCbKXNl8x7lVhRAn4cHudN K/FGm/q03SlRibCEsgnsWZxknJBbNH86QbhvH95NGbY7GkIQ27zmKsfzuS3D9Tl5 a9YwChxrk49U5e+t8gmkIiZgGL9HdfslAWE7bfr2tGp8rRN0tIVz+T89F0CZ0Lob OgG4hmPgVyV7bD8n70sIYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1780263992; x= 1780350392; bh=sloNsprdlXvkjeTtMi/sX+bK1CKK0vU4yLyBSdYlTzU=; b=p p9nZZlGeGZOK+WaTwP64XfS018JAri2gIfq/DZn7ebHzltO+OHHexdL9Ktn+lLSp BXZPrksyXW+SXkXR42S2dAMb/doN5iOuqK/FEBXmtBImFJo70Nb0RmWEHdGnBD2Y ZmMZVU40stx08US/C5xc/roSn8I/igfm6pKJJb1QU0s3hVTMuFBih/Pq9r6M/FBr U/iaHtZcuL/m1rqH+1zWWna4wYGDNHCN1Z6EkGulHHSCkB48knmt++A1OFly1fep l7gOcsUe1S8uvtcWaKxB7t4/KKDnA1tw7pK+OAHoPadnt8sfDyu9VJjzdzNJsHnu YjlAH9QbraL4IEiWB9lag== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFrMssNr7uwMYxyfvRvReaLtWWMJcMH0u/2VgGFXPqzEmkK5zLg5v4Mjnk50jaZAN JgOE0ZqdpAgbwDvC4xRKa6g/IHbtXCIIRJGLIv7aXl3TCwkIrizuMSY+cC0EsJoiUPlvNZ AaF1k5cnhL4fjL7WLk9d/PnLZd8lh5lNISBD0nZvnMTw5D9DG2wf/4KAxY2T3COPWfCVgj n/k6Rkx9EvlJ0r9dV2shkOHJr/uQ50JRVC5NglHl8GL7pESR6yas0MMZrX8Uzdn+NPHkk5 uQ/O+nHnn6gq/DPOHCKP09hO+ki9i+ITJTb5poKasN9FdbWa3qJ4jEZoRvka4ywRAxnYZ3 YE4UwLEB9CQilSvzOQ/z3dYxdAebjDslK4Cni4xjHxiirj7nrJ3koxx5P+lPM1bw97yGru B7VG50MNoZlreM76HvZ6HA9KBl6W6l9sTkb7W0piDokit3m10YEGy1nj4rXfhv3/VJAk0B tTVOtxBxgZDBSXGNrE7NqtUKZbzQ/M7vwhN/c6Ph7j+MF/0mp9dwGbNuQn/KqAGpZGZrqA ApMTUWdBnKn9uLpPvwjFBYMnqEwhchfESsI2ISuY0wj5hRTjA+yL5Y5r3wVGvij2deScB5 kM9slqZlUEg6M07rljYYqpqNT+xXxTwJ8a2c6KIp2lu2y+knTI/rHFWFqWVg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id F13F6182007A; Sun, 31 May 2026 17:46:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AzOIXBCOgLNw Date: Sun, 31 May 2026 23:46:10 +0200 From: "Arnd Bergmann" To: "Sebastian Andrzej Siewior" , "H. Peter Anvin" Cc: linux-kernel@vger.kernel.org, x86@kernel.org, "Borislav Petkov" , "Dave Hansen" , "Ingo Molnar" , "Jonathan Corbet" , "Thomas Gleixner" Message-Id: <29bdbdc4-caef-4486-8816-84422c23bc20@app.fastmail.com> In-Reply-To: <20260526204306.0YTo1ClU@linutronix.de> References: <20260523093734.A3AR7reJ@linutronix.de> <10BF3F18-4709-43D6-979C-49067707F1C1@zytor.com> <20260526104051.MmQQ03a8@linutronix.de> <5FC3AA08-47C8-46CE-9758-20ECDE6CE018@zytor.com> <20260526204306.0YTo1ClU@linutronix.de> Subject: Re: [PATCH] x86: Start removing X86_X32_ABI Content-Type: text/plain Content-Transfer-Encoding: 7bit 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