From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-b3-smtp.messagingengine.com (fout-b3-smtp.messagingengine.com [202.12.124.146]) (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 8EF982E736D for ; Sun, 31 May 2026 22:05:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.146 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780265127; cv=none; b=T4EW4ABfev7Xe4u8x9B8oyFlu3kZLcGyUdRZfkpTC0zm96mySnYoczGXEc9aA50iOf1iN/4e1d5JuvdCnikjoj8jo8SUkv6+wTPWhoMr4RUlOUj4qy9g4wN2xzwvJKvzmdAoDx7lqU6/8MHYciyVQ7Jjok84YtlQkOQMHzOlPnQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780265127; c=relaxed/simple; bh=qwcePGWSdXdy+8YadzNp6pUKooiz/SFHdVDKClavftw=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=srBgnbLptrGVe2NBaVBilN3+KN8ngrrNXWBDkfLLuqRyt/ydf1xqXAQ6JrfNeaJOz1kpz+RiwYpUb7Vfy/RSjDfUzdY0C6NLTSA1TRUVJ0AtpEsIrr4uybHiPV0fheJlhsCMcL7eHUodObr/rVIR62iQerLLE6SSIf4GQt8pboU= 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=ZNnnwpP1; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=e9G7QdA4; arc=none smtp.client-ip=202.12.124.146 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="ZNnnwpP1"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="e9G7QdA4" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 3ADE31D00071; Sun, 31 May 2026 18:05:25 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Sun, 31 May 2026 18:05:25 -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=1780265124; x=1780351524; bh=5lMUiopmOeTVxK0c7gxR2/yr8YI+6TPXO5g9OTwo/7Y=; b= ZNnnwpP17vNg6kLXFllfeeQYyApS5Sj1qszyc2TbhDPcsPsLrIZxQDdOXBqZVxhC 140PnPcMisCTMXH6YwlWHs6Lyx7EBLtRsjCT7h6S9sfIeIemrE7cRTp+SOGMC8P8 8YrRf+m2LZfwvb9mNq1KKpavxkxZL+JbgtP8p7MGfzT+L8dDKuIWxkhZzzrFp4mv uOp0Cq3zYUI8+v+tpl5C+lUBE6c4pOuaTwuLbqlRPpU8BC9g71nyiaKa2SvNqxoo GDddmuBi5DsSsXXFbmxURMiGlZm0ozPRzLwYICN+PJa1TQZ+BJ1K/Y5tcFn0MnlG AKDEgiRT8u33jaKjMNtD9g== 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=1780265124; x= 1780351524; bh=5lMUiopmOeTVxK0c7gxR2/yr8YI+6TPXO5g9OTwo/7Y=; b=e 9G7QdA4LjghHgnqQf0icJppFNsm8+bZuBGvzcR+tbXTqoQ8kbcj53NSy9qgvQ/Rb YdUBVPz/DaiZwPFVeNr4DAEtWp8QHZpQ6c/dJs90OHrNmGc4R9EpUtY+d3B/t/rL 6AACcx74CeIsZfEvY9PjogIJ6rlH1rYPMefiAzzZ+zWIB0t09fthbdQ9PDX608qZ D23mHIF10XJaVOFabS5T1agNcddONT/XIHDHwHv2FteuPo8ymRjC15czkVQxDKK7 5lgAu0I5xc6B2/ktEtkQXed+j6SRCdRx4OE7IfBX53KG9Iyww8YXlqT9KiGkXvJ8 ywc1zEBxxa1EqWjopiagA== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGkBhH7ilOYlvgELddFUzArCfvDg7RWkG6SHF6q4//tMX9vJfZsllWh49JlEaJS7F vMz1FEpGn5bUTCG+/0sQjt4/W9TECl/hkrto0dFypK7kIzwPIDt/49OfQJioErTpEWH+cV CLPKsme5A9LVfS3qWtGvaIkO5d+vPKwfm5zjws28ZYT9AzIM//2Nh+6yOjd5NEcOdRUiw5 e8JwYZb2Kaor67EGgIbne7vBK5KiIbTMn94uCd3X4Upmt5vnUOpetcChWSGnMt2Ej4lVp8 V4mz1FvZDNFE4hEoC47U9KClTon6ZRP2YJU0EvSCREuvghLU9YNiGXlMA81elO/a4xAOfX 7ceHHrp+IQthfdRQZ1MrezjAb1ryE4X/tWyz96Ku26OWD++Vid/pWKv3k3+KkvSKZ5Pwtp 9onBjLqeEbl0wzl29uLuObDWn44x1cVd9ZQq1ZWvmFJlk0kOvSQa9LRcy7Hyx2OnTzrVkG GXWatgd7NUspwzfRmIAXJnkX6JvcmLhVgJO4aWPGK9tTBTRR1TujG9dMbJtFHFtLmg4OIq RGDippbo/bko/qpGD2ZbkqMOxTYF+LN/lO4Qgd3qUoUXxy9RUjUE3IpwXm3M4RgE3t6gEs C8vk4yC/7dxve7Y89KyDR8Dr1p11V8c4lTScYY3aNroHKPO3P/HvxV4/asrQ X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 2FB8E182007A; Sun, 31 May 2026 18:05:24 -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: Mon, 01 Jun 2026 00:05:03 +0200 From: "Arnd Bergmann" 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" Message-Id: <87e8bd0e-ddb6-4972-a99a-c0fb80faf1ec@app.fastmail.com> In-Reply-To: <20260523093734.A3AR7reJ@linutronix.de> References: <20260523093734.A3AR7reJ@linutronix.de> Subject: Re: [PATCH] x86: Start removing X86_X32_ABI Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, May 23, 2026, at 11:37, Sebastian Andrzej Siewior wrote: > > 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. > > 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. > > Signed-off-by: Sebastian Andrzej Siewior 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. I agree removing the Kconfig symbol (or marking it as 'depends on BROKEN' as we did for arm64 big-endian mode) is a good idea at this time, but I think the timing for removing the actual implementation should allow the next LTS kernel (7.4?) to be released with the current level of support still present. Arnd