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 CDC41C83F1D for ; Tue, 15 Jul 2025 10:31:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FAFE8D0005; Tue, 15 Jul 2025 06:31:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AB6F8D0001; Tue, 15 Jul 2025 06:31:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C22A8D0005; Tue, 15 Jul 2025 06:31:58 -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 3A39C8D0001 for ; Tue, 15 Jul 2025 06:31:58 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E1DDB80451 for ; Tue, 15 Jul 2025 10:31:57 +0000 (UTC) X-FDA: 83666133474.26.90149C9 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf13.hostedemail.com (Postfix) with ESMTP id C9E1520018 for ; Tue, 15 Jul 2025 10:31:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DOJ3ALEw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of levymitchell0@gmail.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=levymitchell0@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752575515; a=rsa-sha256; cv=none; b=AdJu+c55NqHUzI+uN+NJCfKEW70KX0h7PVkSI/XlD2DD2VzJMBS/RGUpZgSxUuLUmrU9LW wgikvaefOBMjen3Zo7Qym5hS9HILzCF5li3BkiuZ4NWimk/lejZBdZzDFtJhPJfDoZn0vI xFFx5LC1yL3OlM0bwlvBizXUXQIo9A4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DOJ3ALEw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of levymitchell0@gmail.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=levymitchell0@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752575515; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=19y82vR2J5R6risS4bwxDT4Xe9S8atzVOrzkj21A8LU=; b=sCGtPPW4KHhWmUy9wSr6EV3LFns28fPSzaT23n4AMTOyAbfDNiydyVF3mVl5tKCe7waGzo dElZ3Z1Cj8v++sD5/dT1tpGya4TVLBRLuIsQc9bkb+xxA3te8iTthulfkEJuwJhJgZZoZ0 xrxu3Ed1WbRJ+G6o6LH871wOQAsWsXc= Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-ae0c571f137so984049866b.0 for ; Tue, 15 Jul 2025 03:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752575514; x=1753180314; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=19y82vR2J5R6risS4bwxDT4Xe9S8atzVOrzkj21A8LU=; b=DOJ3ALEwU92nYoVeH8PoVCUwLXxEY0RRv3uouPp7qwRqK9QcEnD29yhri/9kZkjEFx lNYkmQ/F81Mxx9k9of7RogfnGxL48zjRzc1zCXjg2zSDVa9X8key34/Gj6pfXNGKh4F+ /q7pa63KswTsx68oeCEVkL23iS9LTWA675uW2nj3eFbuFsbfS4JclunbBJREEtjWXPtG JElIPWs39TOZo3X1UVjIk9TlvB4vl2duiSW1UyEydiC3BoCIZhPGzKjzt4TuaaK4m1mm Ree0Q37HPaawKTQnNBrXYXW7p0YuJ93Wwf/1aTNynCPGR/zA+xz78WYSL2aY/cCJQgqI H1Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752575514; x=1753180314; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=19y82vR2J5R6risS4bwxDT4Xe9S8atzVOrzkj21A8LU=; b=oDRVu9oTYs2GdN55/q3JiZ1NI2ihiG9Rf76cLaPjOVV4UCdktdcdw7F0W5f4BS4feL SpJpcLK03QiifHlZVX1uKcWndXPrOAzNrVqJ3yJfEjO9vCYc+WeUu4i0hJlj6C8ZyBng RNBJtpvOJ1qJgbbkhv21AQ3OJYqTcX6hPzufJez6VASbybQhKzLuAiUrxopA4ntdKi0Y QPQAv7qgrAnK7ux/4OilBaVzOTMoZzhanP6bXhTaaSz+ga9MkX36BdLTIp8jpYlt9HRI kX7RzivLBeXxD52365sXg6P0DmJ2oA66yrjHmeKS+9s2w2ptleHpUNj4gnmm3Lq/9WRM qy1Q== X-Forwarded-Encrypted: i=1; AJvYcCVGGw30u1rCrI6hto8kycMaHo0rbWE6TQt+5SpvuvNfsH+k5dvWwVDT0hGvB0T1a4jorhn1xblN1A==@kvack.org X-Gm-Message-State: AOJu0YyZMicyZcXwmcmeuHBqBVUnwthWfK8hhFCBy+V54v1cyez9jAbj CbUwnkya1VX3kF1xLllwAuAHxlr7vD8delC8SkZmM/S2YE+lIsZTaEli X-Gm-Gg: ASbGncsUzvxNcWeYVmY0e2vBqauoukLC/JlV5TzMBKuPnoHjnxXrbbARWxOAt1josAU Cpg9v2sXuitlaq51XmisTi5rAE9Bfnp63R0rbrNGIVn9bQ5x6uu+84FWPPp+LYWx0rIWq5z0hgT 9D5TY6ZD/ffHIiwtrB3wZaE5TosbWsJhTaVAez3VWLwlllp5TGnJQsWOwDunRf/XI1iPY11vI7X d7/uoUlyN/BTRg/uVVmmqV9E8yyN9mLfXyE+U8JyHVJZfU8EX1bjnOFmZ68lEaeZb1NQlrBW33y 3jhzETtG1JHhsYrr8egzJwmaWu6eyPsTNpwcv47R+blkFaMXq7uTA1Vo+SBPJ6qrRRIdqpphOnd zu2YTIDia8Kw1smhbB7PF9UlOS6CCBCjd/QAAqm5FQmgJ7SjJ8mvjF+rf4cE2Dq0BNxp5rbo= X-Google-Smtp-Source: AGHT+IGm0Eo7WMlMpiYg7eCxidmrz8W5QxCppCa1TJ8Yab6+vZVWVdqJFgb9fOWtiHq2hk4a27F8Zw== X-Received: by 2002:a17:907:1ca1:b0:ae0:c690:1bed with SMTP id a640c23a62f3a-ae7012db12emr1692257366b.51.1752575513793; Tue, 15 Jul 2025 03:31:53 -0700 (PDT) Received: from Cyndaquil. (static-35-65-100-159.thenetworkfactory.nl. [159.100.65.35]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae6e8316b53sm964195366b.185.2025.07.15.03.31.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jul 2025 03:31:53 -0700 (PDT) Message-ID: <68762e19.170a0220.33e203.a0b7@mx.google.com> X-Google-Original-Message-ID: Date: Tue, 15 Jul 2025 12:31:50 +0200 From: Mitchell Levy To: Benno Lossin Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Andreas Hindborg , Alice Ryhl , Trevor Gross , Andrew Morton , Dennis Zhou , Tejun Heo , Christoph Lameter , Danilo Krummrich , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 3/5] rust: percpu: add a rust per-CPU variable test References: <20250712-rust-percpu-v2-0-826f2567521b@gmail.com> <20250712-rust-percpu-v2-3-826f2567521b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C9E1520018 X-Stat-Signature: 4fpq118qq7gy7j1wmknuof5g5wa4dek4 X-HE-Tag: 1752575515-55611 X-HE-Meta: U2FsdGVkX18S+A0o6LVhSVPpGM7gOe5+sH4c2ku4RM4GjA6Dz/BQlcoGZODQ3vvSzLR5kYBDsoJxVkGymOuhmSP4ZTWYbjBgs/+gwACT5hvnJOBHdKlvMP89jk8VLE0Lq4Xt1ZQDu+M0ezB7nv7+XVoYXsBE0xpt/YZTovsMWF7vgG3AvAhe4JkhQPfcubkhQSjusPiN2MMBSNTp6Y/txmRc3VrOM1fWdOh0c0+b+FZwhy0LIKPerST7Y6gP6IsLy7BdokS+yXa4lILnCDeEbScW9V/cPpQYo3gh3+6of4/uJR3/TuyFCOP5vcm1oZgHfQ10QHtUxT86iDtOrSDQ8StNh8bivOrq/TDvoJpF+cAgPSdaXTvvHOekW+F/gQka322lM3c+qCuQ9LHhPqRIECgmtpH7ybSRhE0LliPu4PdO4AvxQMOz9vM89qlmVo78oI0J1eaV2xCyshb5YVizC8DPi2FjLUr3/4X5UzvI4w8VkQCFSAxjc6pl9sUvcJEQZI6If5oip+rhlpoGTla30uFh0kHCM3/SmTRkPMRb+iD0k+vudOiWoNTd2nLcKg9VRuztPXeS3+PtzP2A10C9R1d/uw48LzrwnpklKhkSWxZNo1F1a65wzsJw8wSRl9UlM6J5S7rCzRIfRAbdK0wTlDvaWtIqvPKLKLwYpJh+OGQxGcg0lecd7ZxhO0nIrUhKOfXv+3tIIVC6v1pfJbeuMbLW3j1wmERIja2eKD/3FErQgBsNmXSkxyrXD9z6qV8bfjKYHTcp4sBkEMo3mgAEowAZzIVhQ+zxRDkU51oRSyB1iQgGFCkY4yS4WDgOJomAEgwlUe3kIBc9W1VPh/IVU6FnxNYIdV4em09ZcHr6QWpvKBkNMx8nLJdiDW2iQshK+5IA74KMZFNF32Lm+FGiNmWDSCP6DbVnDrzewbEaKOMZETbvRNYGvckDqVQkfdlfm9wdP2DgtBR38YZLDH+ Cba/7/xR fnF8gsEISJGxsLpd+60coNJXiZ5DSf2BFzaN3uB35n+G5Mg9+GEUjJWNs0NW8ksJvX7Y62Nk223qUWAwrlYe8DeABR+z0MEdyEinrGdjUk3DRkPOwDu352YrFhf/zwbfC02fNW4lBAjqORjJaRksX0+f3SRjUNLRiYaSsVN3aFQqtnYbcmJPPkkmFM61pSZIkntok5oHP6ul1gt0wyuEyzuFntWMQAmPtbDnLROc4ezFmF3LvHn/l3emxaxlbLvXXmLq9lfiY9QgXkLMvRantGLjdkZ2oOvhACeCIBcU7qSqOy5brM7Zi0e8nwcRK3wKmKvw3g2Yyhm0X5DT46h+zwmoN/9Z9ao5M97jqI4cIIPYxEaRXUSZ4zovWBFdm1epKss1kT+HxidR+0Yg2pKmJxycppE6wBDlWRUhD16E5USluovrcRGCVhg3kuwCpx124ke4vjFPEqbSsYxIuv87zBCqAXty5HSTRHrGjSOisKWuaggpv1CayXNjVc1nJTzN5vcgsvbsgs9cwAr+M/x2W7DR+pYQosoHmhjfiwIXkDs1wMlmUDojBx7r4RMtWrgeMHTn5 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 Sun, Jul 13, 2025 at 11:30:31AM +0200, Benno Lossin wrote: > On Sat Jul 12, 2025 at 11:31 PM CEST, Mitchell Levy wrote: > > Add a short exercise for Rust's per-CPU variable API, modelled after > > lib/percpu_test.c > > > > Signed-off-by: Mitchell Levy > > --- > > lib/Kconfig.debug | 9 ++++ > > lib/Makefile | 1 + > > lib/percpu_test_rust.rs | 120 ++++++++++++++++++++++++++++++++++++++++++++++++ > > I don't know if this is the correct place, the code looks much more like > a sample, so why not place it there instead? I don't feel particularly strongly either way --- I defaulted to `lib/` since that's where the `percpu_test.c` I was working off of is located. Happy to change for v3 > > rust/helpers/percpu.c | 11 +++++ > > 4 files changed, 141 insertions(+) > > diff --git a/lib/percpu_test_rust.rs b/lib/percpu_test_rust.rs > > new file mode 100644 > > index 000000000000..a9652e6ece08 > > --- /dev/null > > +++ b/lib/percpu_test_rust.rs > > @@ -0,0 +1,120 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +//! A simple self test for the rust per-CPU API. > > + > > +use core::ffi::c_void; > > + > > +use kernel::{ > > + bindings::{on_each_cpu, smp_processor_id}, > > + define_per_cpu, > > + percpu::{cpu_guard::*, *}, > > + pr_info, > > + prelude::*, > > + unsafe_get_per_cpu, > > +}; > > + > > +module! { > > + type: PerCpuTestModule, > > + name: "percpu_test_rust", > > + author: "Mitchell Levy", > > + description: "Test code to exercise the Rust Per CPU variable API", > > + license: "GPL v2", > > +} > > + > > +struct PerCpuTestModule; > > + > > +define_per_cpu!(PERCPU: i64 = 0); > > +define_per_cpu!(UPERCPU: u64 = 0); > > + > > +impl kernel::Module for PerCpuTestModule { > > + fn init(_module: &'static ThisModule) -> Result { > > + pr_info!("rust percpu test start\n"); > > + > > + let mut native: i64 = 0; > > + // SAFETY: PERCPU is properly defined > > + let mut pcpu: StaticPerCpu = unsafe { unsafe_get_per_cpu!(PERCPU) }; > > I don't understand why we need unsafe here, can't we just create > something specially in the `define_per_cpu` macro that is then confirmed > by the `get_per_cpu!` macro and thus it can be safe? As is, something like define_per_cpu!(PERCPU: i32 = 0); fn func() { let mut pcpu: StaticPerCpu = unsafe { unsafe_get_per_cpu!(PERCPU) }; } will compile, but any usage of `pcpu` will be UB. This is because `unsafe_get_per_cpu!` is just blindly casting pointers and, as far as I know, the compiler does not do any checking of pointer casts. If you have thoughts/ideas on how to get around this problem, I'd certainly *like* to provide a safe API here :) > > + // SAFETY: We only have one PerCpu that points at PERCPU > > + unsafe { pcpu.get(CpuGuard::new()) }.with(|val: &mut i64| { > > Hmm I also don't like the unsafe part here... > > Can't we use the same API that `thread_local!` in the standard library > has: > > https://doc.rust-lang.org/std/macro.thread_local.html > > So in this example you would store a `Cell` instead. > > I'm not familiar with per CPU variables, but if you're usually storing > `Copy` types, then this is much better wrt not having unsafe code > everywhere. > > If one also often stores `!Copy` types, then we might be able to get > away with `RefCell`, but that's a small runtime overhead -- which is > probably bad given that per cpu variables are most likely used for > performance reasons? In that case the user might just need to store > `UnsafeCell` and use unsafe regardless. (or we invent something > specifically for that case, eg tokens that are statically known to be > unique etc) I'm open to including a specialization for `T: Copy` in a similar vein to what I have here for numeric types. Off the top of my head, that shouldn't require any user-facing `unsafe`. But yes, I believe there is a significant amount of interest in having `!Copy` per-CPU variables. (At least, I'm interested in having them around for experimenting with using Rust for HV drivers.) I would definitely like to avoid *requiring* the use of `RefCell` since, as you mention, it does have a runtime overhead. Per-CPU variables can be used for "logical" reasons rather than just as a performance optimization, so there might be some cases where paying the runtime overhead is ok. But that's certainly not true in all cases. That said, perhaps there could be a safely obtainable token type that only passes a `&T` (rather than a `&mut T`) to its closure, and then if a user doesn't mind the runtime overhead, they can choose `T` to be a `RefCell`. Thoughts? For `UnsafeCell`, if a user of the API were to have something like a `PerCpu>` that safely spits out a `&UnsafeCell`, my understanding is that mutating the underlying `T` would require the exact same safety guarantees as what's here, except now it'd need a much bigger unsafe block and would have to do all of its manipulations via pointers. That seems like a pretty big ergonomics burden without a clear (to me) benefit. > --- > Cheers, > Benno > > > + pr_info!("The contents of pcpu are {}\n", val); > > + > > + native += -1; > > + *val += -1; > > + pr_info!("Native: {}, *pcpu: {}\n", native, val); > > + assert!(native == *val && native == -1); > > + > > + native += 1; > > + *val += 1; > > + pr_info!("Native: {}, *pcpu: {}\n", native, val); > > + assert!(native == *val && native == 0); > > + });