From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67731C3600B for ; Thu, 27 Mar 2025 16:20:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 66531280101; Thu, 27 Mar 2025 12:20:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EDDC2800FF; Thu, 27 Mar 2025 12:20:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48EA5280101; Thu, 27 Mar 2025 12:20:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1DED82800FF for ; Thu, 27 Mar 2025 12:20:13 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E38B51A0709 for ; Thu, 27 Mar 2025 16:20:13 +0000 (UTC) X-FDA: 83267843106.04.24E249C Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf12.hostedemail.com (Postfix) with ESMTP id F270140021 for ; Thu, 27 Mar 2025 16:20:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=aAlbH+UD; dmarc=none; spf=pass (imf12.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743092412; a=rsa-sha256; cv=none; b=B7cqk0w0tDZ3t6n4Nj5F2OS3C+5KaCHlCfFa/Djhv1tE5UBd78C95Uix3bxeFPoze144OZ vguneIf2KDMBc7VTtGLmmqemH8YO+hNVMPSy2a0l8PkJ5LyeYYG7ZiiLRROVRIvUoiw05Q 9+4CcAvC/7vnF43zMFViFqissogAkco= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=aAlbH+UD; dmarc=none; spf=pass (imf12.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743092412; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=hQcfqS6ONRy4v+VAuw1r1bUFP3B6ufIgzXQvK3yZp0M=; b=oH3Fbr1LePQZ8lqC5fVZyTxQ+0qvtzjYnlftYBLiN9yCuQcWR9SotYeuzm9X/Td7Ufw6jx xp4UlTEFxL5XzSYFo0p2VssWM2Ov4p1G2e04/iuc9GERwDS0VCpwcadg8QeUuS8SP3bl2d CUld8w9JHBjiJcZCaUJ9J5/ot1yij2E= Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-22435603572so25220835ad.1 for ; Thu, 27 Mar 2025 09:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1743092410; x=1743697210; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=hQcfqS6ONRy4v+VAuw1r1bUFP3B6ufIgzXQvK3yZp0M=; b=aAlbH+UDi1xhZPq9A6XSgM1E9zJCDASAzpOsn6YJt5pSNeS8UujDFxs6YCOr5s16vf gmPqzDrpPczUvQf977ZnlQJ8lMVQxq0nTawj0bzDDkzpN6DpazEs8TyqpVwqGGOf0RHR IKnfPZlUnNnvSgDzQPdRAmsSVVFvLRzaEhhqqWC9Vv68m01EB/7e4MQ3DwVRswvdQO5E SK3Bf/9HQeXVkTjQ9F8IbkJKJknTsBQskJyl/53I2RWN1zzx3wZQ2+qK9PUorSkbCAgQ SJpy6WaURcobfcEYct/sUDjLCE5MMflbQpPxLQNRN2L9GJ80etxBPm6Zef8PMQFnqv0Q bp/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743092410; x=1743697210; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hQcfqS6ONRy4v+VAuw1r1bUFP3B6ufIgzXQvK3yZp0M=; b=MchtKPA1jxm6vSTOSC7PFOlaya620KZHqL+lI3QZO1CVw2qijiJihL3lhdcPH/Y6fW hXytFK51xT54uSRU2dAJ5iLc4Drr6TJz7uRW7dYEHnWpJzWvEa/LpQHLINcHblaCOljv QGdCBAMooNLs7+EuqEFN0zbryUsugiLB5vIBF2mQYzW1NhWqFBJug2foeIq33UjWaDQk 5nQEKwd6mnechkfi0DVOQzFteZrSGYCZmakX1MF/zE+QoMtXn/9luStBNJN7dL/J6Pbw OZzVa9tShTnkO7/mulRTDHNqHbTyUQczO2ZSUpbsSF8Jmm/ozRpE/XpOJttVslYOAIz2 Meuw== X-Forwarded-Encrypted: i=1; AJvYcCVaTSxAUjKMEFal4UkHsnWlVdxgwwwdgZGOxIhIUecVHQYdAGG4xCWSau31pBtMAGIS88aXouAXnA==@kvack.org X-Gm-Message-State: AOJu0Yzvu7K0pIEbKHC8bsKNlORwS9I096CJBytU7fA0Cmkg30Pm9ttI s3efYL3WWN5Gwt2fawy2Ct+Zzm70iXWqJpj9fj3j4bVUuuMkqxYcl1qlnIIBDEg= X-Gm-Gg: ASbGnctxMnKdcK+yqMAr/YKKyzmD8do4WlRnys61rut7T8WHyKmJLCOl47Mkeqm8aEO loSPeeklQmhNto6kCUhkttC24E4YzBtVkZRCtSjQfdhUFRjWvtpfAbnb+/OUbtj68vvKGZVmsLM Lp5d7llCf5PR1RLVPOCEZavX9ku3fIwT+xK8mXZr1FQDMtOlzmPrKatAyMoICdLA5VM/HMMmbGE l610ov1hBFybCQ4HC/jVjMUm5F16x+wv8iT8UJ3gVbux3wd+ruzMEFTJB5wVVRfjH0JcLEEMv4v ntgchnLg+kIPMZZpEnBdJdlK+Rir3S86714sYA== X-Google-Smtp-Source: AGHT+IGhXmi8JOjZOP3Ikj3wo/1uBU9qt49Ql5SLHckRbeVG8HWYg9iWFYIxA94kzN1K7mL9F21TaQ== X-Received: by 2002:a17:903:22d2:b0:223:4816:3e9e with SMTP id d9443c01a7336-22804857854mr57168615ad.13.1743092410377; Thu, 27 Mar 2025 09:20:10 -0700 (PDT) Received: from localhost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7390618e4b6sm14534202b3a.180.2025.03.27.09.20.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Mar 2025 09:20:09 -0700 (PDT) Date: Thu, 27 Mar 2025 09:20:09 -0700 (PDT) X-Google-Original-Date: Thu, 27 Mar 2025 09:20:00 PDT (-0700) Subject: Re: [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI In-Reply-To: CC: david@redhat.com, peterz@infradead.org, guoren@kernel.org, Arnd Bergmann , Greg KH , Linus Torvalds , Paul Walmsley , anup@brainfault.org, atishp@atishpatra.org, oleg@redhat.com, kees@kernel.org, tglx@linutronix.de, Will Deacon , Mark Rutland , brauner@kernel.org, akpm@linux-foundation.org, rostedt@goodmis.org, edumazet@google.com, unicorn_wang@outlook.com, inochiama@outlook.com, gaohan@iscas.ac.cn, shihua@iscas.ac.cn, jiawei@iscas.ac.cn, wuwei2016@iscas.ac.cn, drew@pdp7.com, prabhakar.mahadev-lad.rj@bp.renesas.com, ctsai390@andestech.com, wefu@redhat.com, kuba@kernel.org, pabeni@redhat.com, josef@toxicpanda.com, dsterba@suse.com, mingo@redhat.com, boqun.feng@gmail.com, xiao.w.wang@intel.com, qingfang.deng@siflower.com.cn, leobras@redhat.com, jszhang@kernel.org, Conor Dooley , samuel.holland@sifive.com, yongxuan.wang@sifive.com, luxu.kernel@bytedance.com, ruanjinjie@huawei.com, cuiyunhui@bytedance.com, wangkefeng.wang@huawei.com, qiaozhe@iscas.ac.cn, Ard Biesheuvel , ast@kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-mm@kvack.org, linux-crypto@vger.kernel.org, bpf@vger.kernel.org, linux-input@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-serial@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, maple-tree@lists.infradead.org, linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-atm-general@lists.sourceforge.net, linux-btrfs@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-nfs@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, linux-media@vger.kernel.org From: Palmer Dabbelt To: Liam.Howlett@oracle.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F270140021 X-Stat-Signature: 34o3mtyfp5d5jsanzzxm3qszysmp59ab X-Rspam-User: X-HE-Tag: 1743092411-56155 X-HE-Meta: U2FsdGVkX1/7u44tP3Rs/N1Fn9a8p2dO5/OL8A6ByGUN/C1DiAnnxi0H3bctcRReVpZ9ApcAPP04Jlgmmezr3iKL6ZBWwvVrhmkZod6YgOpGdjPEGmEFeTHJ6j9MFOnWezsFGMsrIdAMVXBpCEI6pDx1mQxJhuVs+pyqQ5lhUwnlDvyZRlXaMQzvybY9f61WgPjRFlJKYw5CHGTPc6xaBN/iQ4BDc9Lyxxf0RIs/0OaTkUI3ck187CsueIl6/kQBDcoInQYXioAbKy/pdz0h3fgi+oYRIGVXL95RX5oEX+oERW5Pqssku1CPIYtEk3tnVEdQMKO6a5HaRKXfjQaHrLN8waOa4aGhIwCV92Vos7tRnRoojXrezqZAaH9yOrBy5XWgFlMzbAdjGcwLh0d65Hep8TyAcuPd1YyuTr9dlMT/IGlvyuiDWOk+RUM4TQHRnvSsHBf0TNZDvqMtE35/WnJItIjE3P3vgbtcRfNWKoA2Rrzls6Oc8vx0ZfxZ73igIIfRRStFVHQAYSbCYfdOVtY4iSJ7+vlaEIY+/L9VHDNp9B63/RGx+3AlTValJ7KmLjjEqgetmJbHWynYn5+2NANXJAvF/gU9i6bU+31aWiHG0oQ6sn2szqjipsbYg8cDDGlBqsDK0LbSNrO65rLGgt3aHuLtYT7sAyDbViDJ7fRt6l0wqu4glJuII2qP0ogoBo5eauV2GDbE2pYcYx9PPgi1RJOuAaptAhfGdJMiawqm2mM1iyJ9IlijqVLJKwFNCOMzLBq9KdGoq1P7IMqHfnFOfg/mF1njp4EWRCiCN32ts9dA0sI7dqPOUfE1bhaVBAsRI8n9KtKsXQyAbJulfSPSbtetu1cuENjwDM7mNfULTsFU1r1H5ZwEhgFR50Ri1+lW5cOrpLsnYjxdS0PuFTm4RHWAs7V9f4tbkWSqtJJsExrE/m7f6S03lsGgpLSU3aQh85ChVcG63L+7ftx VZiP+76s gjVUl6+Io5OLfJznea3s0MMZ11zk24lKhbzCjIngO3u9v3opBNcriedZpm0cP8msDDKjUgKXtVBqBJcgHqm1cpcjuGRD+PXfTNNiA+rsEDWZODXtfKvkjV1MmdPfDmjauxd1ntBiF68/0CIymYXgvZZO7+4da1ZW6J66HmGTwfZLO6A24YMzjLH31+XMnnq9DVkUa/rr4R0kn7yO2ckg3ImQzm0rseFHthycp464GFm+6I/R9yiCVvIKifEa6z/0t8DplfBaDkzxWo7+zQHRzxjJW6Ucw+cuEGaaWtEX3+toT2MtD2BFvAz4+BjEtkshQsqcDk89WXbYETsBE+JBTkzsd67qomCTvF05aFVtk8jDXsA/WtUlmTT3JSQnLTAr99gT1s7RJmik36dpBHSuOEQwgnNlYlsrdAmyFWiL0BJXycvRvE4wHru3Rwtv62TFnmckLJ2guBG3RTRieL9jzasNE/ayUj89VRmwn8zwWNqtCHC5+cwd3gme8XSBRMuoE+NXf+tQyZgy+gjjSK7zaH9Gq1ViAQQYMdJV1mI3MCFn2IGCY7nKcgjTdtfM62S0IpIbN4ka/mRiAdw53gIZQRiz21Lj6rbHwE12+WdJA8MQvCNw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 25 Mar 2025 12:23:39 PDT (-0700), Liam.Howlett@oracle.com wrote: > * David Hildenbrand [250325 14:52]: >> On 25.03.25 13:26, Peter Zijlstra wrote: >> > On Tue, Mar 25, 2025 at 08:15:41AM -0400, guoren@kernel.org wrote: >> > > From: "Guo Ren (Alibaba DAMO Academy)" >> > > >> > > Since 2001, the CONFIG_64BIT kernel has been built with the LP64 ABI, >> > > but this patchset allows the CONFIG_64BIT kernel to use an ILP32 ABI >> > >> > I'm thinking you're going to be finding a metric ton of assumptions >> > about 'unsigned long' being 64bit when 64BIT=y throughout the kernel. >> > >> > I know of a couple of places where 64BIT will result in different math >> > such that a 32bit 'unsigned long' will trivially overflow. Ya, I write code that assumes "unsigned long" is the size of a register pretty regularly. >> > >> > Please, don't do this. This adds a significant maintenance burden on all >> > of us. >> > >> >> Fully agreed. > > I would go further and say I do not want this to go in. Seems reasonable to me, and I think it's also been the general sentiment when this stuff comes up. This specific implementation seems particularly clunky, but I agree that it's going to be painful to do this sort of thing. > The open ended maintenance burden is not worth extending hardware life > of a board with 16mb of ram (If I understand your 2023 LPC slides > correctly). We can already run full 32-bit kernels on 64-bit hardware. The hardware needs to support configurable XLEN, but there's systems out there that do already. It's not like any of the existing RISC-V stuff ships in meaningful volumes. So I think it's fine to just say that vendors who want tiny memories should build hardware that plays nice with those constraints, and vendors who build hardware that doesn't make any sense get to pick up the pieces. I get RISC-V is where people go to have crazy ideas, but there's got to be a line somewhere... > > Thank you, > Liam