From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a7-smtp.messagingengine.com (fhigh-a7-smtp.messagingengine.com [103.168.172.158]) (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 2F11F397341 for ; Mon, 1 Jun 2026 22:46:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780353962; cv=none; b=XSGae6/MhoJUMgk0cs18Z5j/M5SQrfFqIsZYQ9JePG4CSbbkmdY5qe58SLgtO+JVbI/X6RKla67iCCcf1iX+UyzzWwL2kFQe1nJas+5857ICHSkPYzVbmf1Kpc7/OSFDByH7VWN/3sr0XNa8XYJN0exOAvs28TEUGbGPVJ8g1eg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780353962; c=relaxed/simple; bh=2vAqIA0hSB4uXYy2RxNd9Ppb4qnUx51bR2xBxE9/qhk=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=LpD7gnapJJxK4hIjLLwcutdmT/7LcxnbDXbsqJmp5dAk9USPbdg4fzMkwMNGo1DgoGgdS39E39NnI2EPHvJIf4CcQbuP1E43lgdlONSJoAMsTQW43iD6wyNE08KeCHomx7EkUbUth1UT4Oi2+So2HNhN78tYFGYmtoDceRlocIo= 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=goJXusS7; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=feney0da; arc=none smtp.client-ip=103.168.172.158 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="goJXusS7"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="feney0da" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 448FF14001A1; Mon, 1 Jun 2026 18:46:00 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Mon, 01 Jun 2026 18:46:00 -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=1780353960; x=1780440360; bh=ldNn1fQ14qPNmKlS5ZbBeOReU6KmI4mKYY8l5O+RW9o=; b= goJXusS71S9Jq1V0Av74iUVrbB+JAQ3VNRqYiiiF/Uic7IMa2CFNnL5xSmTzNDoO t/MHeZiZdSX3GKUfaUvY92oHA9thGffcLCqfPZXDW5l+pAbXGec6KbbFYTR61o8u si0ogxMl3PG6sl+uF8kEGs7VLL9kkc0jwP+oN0MtdCNko8/A6LUNUquLxpzriops Nu+Bi+OFAPxgStLE5WDvd+HRJCOrKQTn5QBYG+FEjjCNK0HeHlXyhR6NpHvRq4+1 77PlHLk7BqRIG34obFG3DRCcAGatEBy1lXEAR+4iWzaXfT206LGv1/n9Dbdj4fb4 3MNjydl0KL4FxGQXx/17ZA== 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=1780353960; x= 1780440360; bh=ldNn1fQ14qPNmKlS5ZbBeOReU6KmI4mKYY8l5O+RW9o=; b=f eney0dasyMPxtxcAaPaLWp+Qn3VQ40glynkezm7IGPiyWQGeVV3wOVJgKItaGhOT EErRfBr4or3SjrWRFY5RwJrQnN+uMGZL/WMb3T8J6SOuttWeJL/ym+ggIfowY7b1 1/Q90fTz5IeJTm60nk9c+acW9vsp2X2d0VDSVT+Y32sTxIgi/OTNOStcGaLIW+t2 mdoQCUveu/8p3Z8sTc9EsxprkmIrhhJx7eoii+/tcld/KpQXU1k+jQNqIOmGN1Rr 4raftWocr5OBWYirl7ITtgS0eWOvwzE6uOXfgwzf9Ib2JYoH5ZRhxzrxrl1RWrQP OcInMmMjXYacONZbBMopw== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFoMwa8RYh0H5zXHQElp0JGcOUp3TGEveIiIKInZ11vd0hn5/XZQXa3lfGiNZUaKe EDmMAi4BH4ydPTGmNwPItyZ1ib0iCj0JNMltkyPvkDF4VlSdiHWW0nOZORY0jaIOIErefc UI5R2XB0t09ewnbpmjA4qq8wW+PTbj6IAjapeK6MkjdaMceOX09+4Jp1O8KsTRekJ1XEw0 +KqUVjolcCBoFnjPvbt0XenmIv3e7NnxKYOmxFgdGUtcuJIS7QNAc8waVWNi+kNYs6SGTj 2dFzj9qd5Ov9feyavd1t/kYMSeaGluLKKuyf+9b/NIQdnuh/u67erOpyod1eehlbIp08no jKMhgWxute9DEOqpwJUx+x4UTtILIE5OGcebHh6AVtryV6LW6iBypgMlAH4r1QoleCPDuS g9/K0mFwXrckjVCdTnDSWvKnvM6G+rQN+gWn24kqO2s0VRfJ0WNdpi9jrNXu3DOTes5DmI kkK7U3wC0f0G1qyIW+7RHXOAYQTDUZpUyH8M4XvEhwJgLC2QHAXwPWNOiLBYcwQE3uHtuN nrfKMT+zoZeAu4k8uNESRoeJ/njSUuplqigbJ1PGjRcjN9ywpz/eCckwooKX5ZhlYtosbS jF8u0ILl99zOzB7slE6Yx0fKbX9zNfzk/G0RxC87eMpmf1XBfV4pK4/zlGcQ X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 8CEFE182007A; Mon, 1 Jun 2026 18:45:59 -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 00:45:30 +0200 From: "Arnd Bergmann" To: "Sebastian Andrzej Siewior" Cc: "H. Peter Anvin" , linux-kernel@vger.kernel.org, x86@kernel.org, "Borislav Petkov" , "Dave Hansen" , "Ingo Molnar" , "Jonathan Corbet" , "Thomas Gleixner" Message-Id: In-Reply-To: <20260601214456.NLyqoEer@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> <29bdbdc4-caef-4486-8816-84422c23bc20@app.fastmail.com> <20260601214456.NLyqoEer@linutronix.de> Subject: Re: [PATCH] x86: Start removing X86_X32_ABI Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Jun 1, 2026, at 23:44, Sebastian Andrzej Siewior wrote: > On 2026-05-31 23:46:10 [+0200], Arnd Bergmann wrote: >> >> 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"). > > Okay, that is point. That would be something like new Debian distro but > still the old kernel. Right, or maybe even more common an embedded system running an old kernel that a SoC vendor has never updated, but using a recent musl build. >> 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. > > I see. That is unfortunate then. > > But just to check one thing: From the referenced commit "ioctl() is nr > 16 on x86_64 but 514 on x32". So the kernel knows if it is x-64 or x-32? > But we can't reuse 514 on x-64 and return -1 on -x32 simply because the > pre v5.4 kernel do the ioctl() instead of an error? The kernel only sees a 32-bit number, with bit 30 (0x40000000) set by libc in regular x32 user space, so x32 ioctl() would be 1073742338 (0x40000202). On newer kernels, the bit gets checked in do_syscall_64() so it has to be cleared for LP64-only syscalls but set for ILP32-only ones. Before 6365b842aae4, the bit was just masked out, so it made no difference for deciding if a syscall was valid and was only checked in in_x32_syscall(). On syscalls that are the same between the two, the bit has no practical effect today. Arnd