From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (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 11D2130148C for ; Tue, 2 Jun 2026 16:37:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.148 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780418240; cv=none; b=KxY1TRpaIioIS7zoo7R3AwZp8FQ9xtKPmpRh1Q6VExD0ZiuNUkB7PyDrvoXVt0xNo6O8R01MjpUfAlG8tb4pxO4z8ay+HzFhszAppEiVYZDzI2IcrfNbgfzDWswom0HfwEsIUcOBjKiV6mgjNoPctYouboMG6Ow9KYEP7oTuXqo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780418240; c=relaxed/simple; bh=e7TkcgXWXeyQmmkaTrWpoTfaYiBKdWaFGi53s05ScN4=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=jQ2CR3xVcS/bBuR7JzACWlhOhB2a79YKlR+Gyal70HhAqKrbXqq4ni6/6p1G7R9vPGDfbY9Uz6vbtk5HmwDPDYcyLlk82mT5bAwSAYebt9IQzIRhWgZKgFfiONIhzCBnCM8V/BrBBXky+2POpRiL0tX655iOCmCNJFsDXExgHl0= 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=kN/R2W1H; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=csnT3x/d; arc=none smtp.client-ip=202.12.124.148 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="kN/R2W1H"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="csnT3x/d" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id D32151D00181; Tue, 2 Jun 2026 12:37:17 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Tue, 02 Jun 2026 12:37:18 -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=1780418237; x=1780504637; bh=98cVngmNySe/wAhY5JugsyLSvdXgUG6+teSl7DIh1fc=; b= kN/R2W1HcsW/8ZKTTnU/NcGEv8n0rZTOYHuxTZF0bE5ZDK+Dp+KEAlDvHDmXm+Vn 5TxinWA0PQXZj8XK/wPugzLkKT0KuSy6VDyN1P96npC867imq/1vqBCk7FIJFQmG hXm8KFEdTkYetVouV1Rg99N6XJujCid3P5Amji9zKeodTQK3fFI4WW4Ua7oPkrGn /wOmvxDdSs4joqkScKfnbPZFIr4pLiZsSjrmCx9CL81mWpjct258sBZTBO8bwouk /uHJt/5ENd9oFlmvL1uxZFHDpc+ADoUXOXHUc+gYNGtZ5tluQRCuZv+S/estiKns pByY4puDi9QGJ3kQdhExdg== 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=fm1; t=1780418237; x= 1780504637; bh=98cVngmNySe/wAhY5JugsyLSvdXgUG6+teSl7DIh1fc=; b=c snT3x/dCd15z7hK2uDaKSaLztY/R8EyIVmezTFhx1Khloj8ix4L+bijLaqcP3nlg zD/tJkK5LEWtHjJ1EiPSeW2fG0jBMMAsUaeEpEUjlj+iABItWYgRkR4ZUg0YDUdm Z8jtFh2vuMkG62X3TCQAHl4QvByJuWx5F037qBwJXlB7tOfL6rwGeYWXEFTy79Qd zL/dwktZjoK3GqOG6Dzx6Y6U5z3IddMa6oCbUNM9fwRAYqkhXsBkzAB06U3/jMTP WY6lzmTs+PhiuvFrgJGEiLeu21NJSSwLO1Jyx6gfyz5Lr9AbwmknAit4/EuLr4Gd 6Wdn9aTpz+quA62H3MO6g== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFIo7QTdMnMfUrFDni4gnlcPFUSwhsORuixkepS8CPoXmBEkta+MTzLD9IuHpQFWN Mw3zxowEONiKXgT9yQTF39hkIPfUFFsf9y6gN316C+WX2bh+GWmit++CHV8CPztag6R4d8 HyPC2hoHUT7frW5ti9aMjoN59hXP5dyQfx/gVVfk15TNBzqOSOTxmc9iIWhiKyRf2FcMYW 2a/u+cxXH7zw02nTrsN0kWfcGsfFUCYU4wcC0to1m94bsynvmJSbWUXl28xpDuA+JN0Qjt qy3YdJsidzZD7osBJ7ZAjsdKrtd7fzdFy5LRR/Ki+Bp4cSxH4AepaRy9VtqWC8UYYTpQTU 7BLoZfF9siS8VVwM5BiP6STtfDuZwpM3+x9ZnhcuSj9zrY1sQdl6NnwX0rOh005H6p1ijj R1Rzt/ZwWVK/61YKOgt6k8cQKwyRSBVuOC7PcyZyekGxvuQ/l9TioorvKpYn12gdpA7tPl zIoKOmV90TzcalS/Gc+qSYniXKgRJoqFNJAKBmTsw8hAdPdL/+VllW66pbGTWjboLkNsjK C7ba2O4eam/YLwYJ79WVVv8NHO+dcO/oyOMVItDv8Pz/AlrrYe21R71TIB8VtbgSBMLwaD Rw3jm8+re2v/7k9KaagVTpRljFXaXB3vV9oQ1gNbn5D68gZvlYRNlCZcoTbQ X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 3CC61182007A; Tue, 2 Jun 2026 12:37:16 -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: Tue, 02 Jun 2026 18:36:54 +0200 From: "Arnd Bergmann" To: "Maciej W. Rozycki" Cc: "Sebastian Andrzej Siewior" , linux-kernel@vger.kernel.org, x86@kernel.org, "H. Peter Anvin" , "Borislav Petkov" , "Dave Hansen" , "Ingo Molnar" , "Jonathan Corbet" , "Thomas Gleixner" Message-Id: In-Reply-To: References: <20260523093734.A3AR7reJ@linutronix.de> <87e8bd0e-ddb6-4972-a99a-c0fb80faf1ec@app.fastmail.com> Subject: Re: [PATCH] x86: Start removing X86_X32_ABI Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Jun 2, 2026, at 18:02, Maciej W. Rozycki wrote: > On Mon, 1 Jun 2026, Arnd Bergmann wrote: > >> I think the main reason to remove x32 support is all the special >> cases we have for it where it is different from normal 'compat' >> syscall and ioctl handling, which leaks all the way into file >> systems and device drivers (sound/core/pcm_compat.c, >> fs/fuse/ioctl.c, fs/read_write, ...) as well as user space >> trying to handle 64-bit time_t in a portable way. > > FWIW it's no different from n32 MIPS ABI support, which we've had for > even longer and isn't going away anytime soon. So there's undoubtedly > some x86-specific stuff there, but generic support for an ILP32 ABI is > there to stay both in the kernel and on the user side. For the parts I'm interested in, it's a huge difference: MIPS o32 and n32 have essentially the same types and syscalls aside from the few structures that describe the actual registers (pt_regs, sigcontext) and the syscall numbers. On x32, there are custom integer types (__kernel_ulong_t, __kernel_old_time_t, __kernel_ipc_pid_t, __kernel_uid_t, ...) and alignment rules that were intended to match the native x86-64 types for simplicity but end up doing the opposite by requiring compat ioctl handling to be aware of the difference and implement a third case when the x32 version is different from both the i386 and the x86-64 one. Even for the cases where x32 ends up using the same syscall as x86-64 because of these type choices (e.g. gettimeofday), this still needs a special case in the kernel because all other compat architectures have a shared compat version. Arnd