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 C2A64C36010 for ; Thu, 27 Mar 2025 16:20:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9DBE280102; Thu, 27 Mar 2025 12:20:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4F812800FF; Thu, 27 Mar 2025 12:20:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7996280102; Thu, 27 Mar 2025 12:20:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 89D5F2800FF for ; Thu, 27 Mar 2025 12:20:14 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 85813121038 for ; Thu, 27 Mar 2025 16:20:15 +0000 (UTC) X-FDA: 83267843190.28.6259250 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf16.hostedemail.com (Postfix) with ESMTP id 581B3180013 for ; Thu, 27 Mar 2025 16:20:13 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=GNzVe2S0; dmarc=none; spf=pass (imf16.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743092413; a=rsa-sha256; cv=none; b=c0uB15IdWfTmurWbqZO08YrFoxGr5gwLrfkByaqkjIV5+n8LXkitpzuvNzJLEWiXnwGjVo iJ3JFlvLgeAjovJ2xb9wJwLzFtqCUilZR+g8u++eAoe/6C18Zc6+rYOTYq4VCqy1lvH0zU ctHkmpPgskIeSrz1Y6Un60F3PERo9XI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=dabbelt-com.20230601.gappssmtp.com header.s=20230601 header.b=GNzVe2S0; dmarc=none; spf=pass (imf16.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.214.171 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=1743092413; 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=kX05jx75Xb8+ENPYRjK+Gc3Ht1e9kjVMOGIod7/HdTg=; b=S313pcXoS0SyYd++n5gpqOM3GkJDz3cCplFxP3UwuWdp/cUexElTAltAu7Oq0v2Sk2b/eC gMBOm95mR8XbG8hX5gF1juqhooJW+NC8BI2I/XYzcPffpVo8rxJiGQAijByDFKHE7ES0IR YRKSNx/q11d2/Wi/0zFaE80uqTjKeQw= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-226185948ffso27191845ad.0 for ; Thu, 27 Mar 2025 09:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1743092412; x=1743697212; 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=kX05jx75Xb8+ENPYRjK+Gc3Ht1e9kjVMOGIod7/HdTg=; b=GNzVe2S0EMvl4/Ly7RH8qZa6VCHpBg0EgZlWgAHAZRf9Cp7JnYZ2Mb95wJEuolx7ly O2w7fPn3KEGhvV9xHhg929qkn+Dk/GzfHdUr2pU0lqDqBvCjbonH6VWN5OJouvpUff/m uYg/k6NiQCBYJ9U4UDstPzYHzFs4ZEcLxoIVccmgc6kk7x5EprN2ShjnOoGlwVxgjIu+ i2uTysftmAFzVzBdapZVnIG9AL+SD3HK6l9oN3Or/E/0gWnjoBgu57e71yDqrDKeIxzB IVLNctj6rTx/jVyXA2r4nLmwrKGbBkFqbcB4Ig6Q2nfDhVlRb3w3vXFxW97at4pKaKFJ jE4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743092412; x=1743697212; 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=kX05jx75Xb8+ENPYRjK+Gc3Ht1e9kjVMOGIod7/HdTg=; b=cn0t/yifeH0st/M3xQV0gmg6vduAhbekJRqoEGWWaFNiYBDUCPleuo/cXGpw+VZx1t Jgon0wcZg212wZkk4XO77LbNn5wLoendrUm9Ucr0adcgu3Yxr3hgH/d/f5p1MzHv7ThG BYEfnvPUUEL/Q452KTaafOdrBCa0jc4WW7FTe2RB5Ffnv2xCj5qhLrp5MBtvF+p40LTo 9jpI3GneB3OVTTfhf9WTCJem3p+hj8Nugil3KCGYUzjIy4YtikxPmyy9P19kEcpBMiZq EGhzJlarxyS/g35d0SQBhVYUsFXEwR2GKrjHGGywDkPSxkBx45t82K/GqVx2bknXENXo V1TA== X-Forwarded-Encrypted: i=1; AJvYcCXAbV0DDFIJ45Wt4AQty9KVDWi474MTi/Dkl8LQJ4Y2BQBIcu95APxNFJyTJpHy/hTR/ltVctMRVw==@kvack.org X-Gm-Message-State: AOJu0Yx3cKptuvNuGIH42PMAtBJoA45gwcd/OJL9K3yX10AglkIJwdZf MlcnDw1iWl0iTyeMRnAFedX/MVY+o+B7lhcVziNLSwCfhGokJZJnRUwXi3jvINw= X-Gm-Gg: ASbGncsSx4eJoWUXQ4HJQICEtWeGP5n/mq29sGJgne0HShb/lAROUzVka8AtvZSZxA7 orjxRHjU8IZw5lsRxU64tl3R3/JdJ8L8hL1x0HNNY5t98eN+bsNAw3ArHY/Mk+LB/TFEOOkRkwm 4KkULGzJv38jhPZ88MqlvJehVt2d33/oQ9zJdH3FiyLW2ReLXl5Qcm2nqw4a3ngtPoRVsJEjTQH 6B5g7NmcBHfh2eN1jBfPQP9htBcGOzdg3U7HqUWgsfR7Fx3Zlt2xT904zVpSZ0vTM5EaEKPUvBN /VUv9LTcv4wua/MOPF+X2OcUt4ZLidD0eHemYg== X-Google-Smtp-Source: AGHT+IGClNJzmnXOK1L/PFNFl5ogZb2gMU/Eqg4X3l9WVxApkZth9g72YE2t9vJ4dK3KZhjxhfYK+Q== X-Received: by 2002:a17:903:228c:b0:224:216e:332f with SMTP id d9443c01a7336-22804968a3cmr61064755ad.48.1743092411962; Thu, 27 Mar 2025 09:20:11 -0700 (PDT) Received: from localhost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2291eec780bsm1682245ad.19.2025.03.27.09.20.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Mar 2025 09:20:11 -0700 (PDT) Date: Thu, 27 Mar 2025 09:20:11 -0700 (PDT) X-Google-Original-Date: Thu, 27 Mar 2025 09:20:02 PDT (-0700) Subject: Re: [RFC PATCH V3 01/43] rv64ilp32_abi: uapi: Reuse lp64 ABI interface In-Reply-To: CC: guoren@kernel.org, Arnd Bergmann , Greg KH , 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, peterz@infradead.org, 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, david@redhat.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: Linus Torvalds 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: 581B3180013 X-Stat-Signature: dm4tqhaigyxod7xwu96mydm9waqr7dfm X-Rspam-User: X-HE-Tag: 1743092413-44301 X-HE-Meta: U2FsdGVkX1/Rx2f3+wkECrje04P0Kg5Ns6cufWF8cr8hhi8TMuFJ/0z+HNYy+zJcgldNtHiJyx7bOc4d5SwdUJLIPdjho1lqstRw+v58iRwf+VlLieeGuIsTtZ+tCmtAmnbCTUSDnB0wp+/IUIH8ACeSAnJUWW4WuC1uu2S9n72pyr8LfvTCFHueLLsEWCKLxSpVEIwKu4I9joY/mDcGckMwJRHPAusSetfx/3enjafNuNUnwVnDNrzfDaArqx6SANkPpNslnx249PWoPZa18BPEWbacLdEt0X+V2qwxLuSREFQK7TnbrUW2XyA/ms+TASaQrSzXNeVXOiRPHTNPVwv9M06ILoU5gY7TszEeW2eQxbP+r/XZOcj13Bp6sHRUI5czTR3WFiNaxqmt8evwVIBXtD3GRGUmHkbw2lep42ZL6ThER2k9189F6qL1nFvouWpJLIfGmlRHtFMe/pTxUUx+aDkO7I0SBZME+lIpWjEVQjZfCKZGWKAqREY5f6btZsA4sgIB/omYVIkJIwI8ktLq9t2TRCD2YO4uQ+Icoxgb5BDUxb3XD7FYJB8Ime3tIPb3j1KrPKZoba/4c1VmnCrznQ73DL8Dde8vLf9zPDTUBtNCiso0BSjOmqH/DAMhp2w05Sa65v6H1NCSyNel+kt1ZFVkOolqEI2whjjLkIeM/P/IXTkJPE+of+BP6qLe1RYhvmTkfy+nExGvLCdYCKG9qpQ7Lx3hLRNOMUMP7amTH9IOVwrVNfdzZ4XPf9v75hQrx70ungCYDhh1QRvTZM7z5ye+f5twhaOwOhwyaj9vwO674mFTv+qmuUR67DrKxVTnSEiGZ7B7tpqx9JVIdthAOSj/9m1h2nmT9CdE13kbsRwvAb2ldv8pCh41Qusyr9dFsfuZWG7hkLxx0vDnxvuULgxO7th8r0prpEqUGWOzNjyjXheiReH3LtP4n7N7LI5yzfci4x9U+jbNt9M +5Flmi5m 27nxTBls7s+PihRsz3jjuqqJBpGKZTAHemnhJM1gGiEM6xGxFh01t2wG16mGeliMomM81oFugnK0LvThGP1D/agWfwNmWvHssKE3Z3txNq0WQ5MVviFvdFmbQp3iZ2Lf7rui50TAxTzVLq0NYQt6NEwGZc94/mvAerUzJF9d11bAUbF04BqjpUiKcnMFmyrYy7kiJ67OfaXywLnCVzAKEvelbIxlYdUx8Sh3kzWO5DW08+57xNoaR4OU7cZ5I/5dzhva2033WO1pA6lXNVA/+V/ugbBacn3JUptSSxC6IEiPm7EgWbG5WUZztCFySsrAw5wmUCXhXd2is8jRS/gbNTdAbes03/lmFSSR8miIZCxKP1YCjFhQs9XWorc79jYj1bI3EeZS68B+a3nKhk3iX7vlyr0EifruYaWxtUBkGpHg2u0wH0MIJFbzIfLJCvnnh22jTBoft2aVDHcHcPxwdRl4FscK0i3oDPfQubQgcDMz5nbdu9bsknZ4JYc9WNNoRAvakGxdIdpbxnv24MotiJyjINXiU10U2durP1JtMn4OflOXkncoaPqbIrEZx7NT4/VIB 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 13:41:30 PDT (-0700), Linus Torvalds wrote: > On Tue, 25 Mar 2025 at 05:17, wrote: >> >> The rv64ilp32 abi kernel accommodates the lp64 abi userspace and >> leverages the lp64 abi Linux interface. Hence, unify the >> BITS_PER_LONG = 32 memory layout to match BITS_PER_LONG = 64. > > No. > > This isn't happening. > > You can't do crazy things in the RISC-V code and then expect the rest > of the kernel to just go "ok, we'll do crazy things". > > We're not doing crazy __riscv_xlen hackery with random structures > containing 64-bit values that the kernel then only looks at the low 32 > bits. That's wrong on *so* many levels. FWIW: this has come up a few times and we've generally said "nobody wants this", but that doesn't seem to stick... > I'm willing to say "big-endian is dead", but I'm not willing to accept > this kind of crazy hackery. > > Not today, not ever. OK, maybe that will stick ;) > If you want to run a ilp32 kernel on 64-bit hardware (and support > 64-bit ABI just in a 32-bit virtual memory size), I would suggest you > > (a) treat the kernel as natively 32-bit (obviously you can then tell > the compiler to use the rv64 instructions, which I presume you're > already doing - I didn't look) > > (b) look at making the compat stuff do the conversion the "wrong way". > > And btw, that (b) implies *not* just ignoring the high bits. If > user-space gives 64-bit pointer, you don't just treat it as a 32-bit > one by dropping the high bits. You add some logic to convert it to an > invalid pointer so that user space gets -EFAULT. > > Linus