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 19A44C83F21 for ; Tue, 15 Jul 2025 14:11:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A06F36B00A2; Tue, 15 Jul 2025 10:11:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DECB6B00A4; Tue, 15 Jul 2025 10:11:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F5746B00A5; Tue, 15 Jul 2025 10:11:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 80A9A6B00A2 for ; Tue, 15 Jul 2025 10:11:03 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 29E605923B for ; Tue, 15 Jul 2025 14:11:03 +0000 (UTC) X-FDA: 83666685606.20.FC52439 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by imf14.hostedemail.com (Postfix) with ESMTP id E0B4C10000B for ; Tue, 15 Jul 2025 14:11:00 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=E5W6ib7N; spf=pass (imf14.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752588660; 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=SNZvbkqhFe7+R5IRsiZs1kxLolypY/wQ9f39IZDObm0=; b=UwCfZfRHRJX1ieXkXe5zRhKlaByollH137IaQj4yxjmEmg7lkWtXtxGupASojYyxnLiZWH IKQSFZQTWX2AHdIkFXgBmLHvbFDQ4Sg2n2zHksa3JlAxNAb7u+pRhAKJa15hQQie28BmPp FSJVHj0EYZfESBXeetV9bbfMsJFsa70= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=E5W6ib7N; spf=pass (imf14.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752588660; a=rsa-sha256; cv=none; b=RgE7W8gbqqFjZq5BWsyo+Y9xBiwSUi3Mv4Be79CLFnsoNndwM3/3r/bnmwCV+JbztQvInC PT2+Q37Fy3MM4qbAJW+oEjsdlr7s7SgAy4Mn0JfNdULTz9l4IrsVqxo0doHDAkiZ2lwWdb PD4Lw1TQKJ29ARB3uFfgKyGLCaia+Uw= Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-6fad4e6d949so24188066d6.0 for ; Tue, 15 Jul 2025 07:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752588660; x=1753193460; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=SNZvbkqhFe7+R5IRsiZs1kxLolypY/wQ9f39IZDObm0=; b=E5W6ib7N2HH7vKsOdSHkPRMXxIo8CvF3xUfQA/tidtEOSYgkZhAMzne0bYjJL92sJZ kTXVq0fnonUnTun8nOl/Y2761NhtQAbz5i5oFCXj3DzS5mvkaFJno+SZ1uuzBS0BB210 aN06iWFlN8xPpbTBi9mWFuLO3wUQauVcD8NkkTw4KUkuomncgfxlYHz3+iPg8sXVJNTv wPM/QcuTf9EpQ3vBCbkN7WNDYGu5EWpfZCTXPV3biNrpQDs+74tJf/QZ+MCAETLfv1Lt 8IDz0KoEQXQ/YKqbEqmzM5RStHFmLI0V4ciwJHzbseWtwlGZoPEP4EyjRUzSGiv7Ho56 yPGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752588660; x=1753193460; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SNZvbkqhFe7+R5IRsiZs1kxLolypY/wQ9f39IZDObm0=; b=kENl5GAtyHSwEgRhnTvZ6ldKhVhbQg6ks8JFYV/nUGycuZEl9k8LrCfZ1VJhfTuXSc rjL0LJACO9qm/1ikdsdI09OKBa58DLxzYehXJ+x2F79Fdyap92dNh7fpbMVfUW8Ic7d/ H5KDZKW+C6q415+f5Pe6Cn+2ftkeOlmujFDGAaFwzcrkMyHgh2LZf4PGbJ4IbC+w1eya qEyixXo9RbT60DgSZmii/4/dUDVrIU3B8ot/JGYGcUKzMnXBatfpmyHNth5FGZwD9k/9 ooPtdwbgPC1Fbi3MDc3/TxTN03YkvXSZVcxtF6FaBnDLqUNMoTMR8E+5e2jT4nMLWKnR ZAxw== X-Forwarded-Encrypted: i=1; AJvYcCXHoAnIWTsraXN1Zv21JIxd7TgPr+byrbrTrYV93UqwRaUSy27II68tT8Hoi6zkhTS9aCu+CkYhIw==@kvack.org X-Gm-Message-State: AOJu0YyOAdhzcpdFAiTRMemhhiLAZ3orV/Ce2lR/Sc00EauaDwfcCfoQ cjZbgPMoJEzLwskMar9es+/GVmZhUNPkxK4bVRwkUS+X49SJ4FOsanQh X-Gm-Gg: ASbGncsByUAJjnAWkguGwGYFhgPJC9MNRl4qhCeBPSNsyWUR0UrycaE0bn/Hc13fRvu MlfnMKyaBKSFumoclhn8Pk24Lk0TIYqPRsSth15a4N6Z/JqInAS8ep//9FgssrWVN8FVQXI0G8B l8I65wMYiBRTDvqcrJzcw1wkYAZAl+eZmFv2OyJWIXi6i6wxS7rguPubpaWtgpzpYsUyMkWBrsu uzuYuKoZudQyUpGAIiXDl24W+aD4TTjxRuSVI4ay4HKcfPfLalDBXrGE/YM68Z+ZeHEF+5mP6Oz FK+DVa5zs0Y4CRq22hLuqibmmQKpWMNGTrMOgqykoieZjOFSmYZnIptCmfO9/zepnlxO43MeqQM UcH/jFSNrpdBIEGLVbh9xJOUnPOZBk+Q8oryMazwYOHi8Ymg20qwqXMx7vUCUXwvC/12rwMzJ98 6QxETMWj7zoMB6M7rfSBDUd74= X-Google-Smtp-Source: AGHT+IHlB/d7fN0BeQNV/gjZ1+bEF0VFfNvi38+Xuu5rHwPY0OQeFD83BZPuL5j7LqQXziSyrHsi5A== X-Received: by 2002:a05:6214:dab:b0:6fa:c6ad:1618 with SMTP id 6a1803df08f44-704a429299cmr314498946d6.27.1752588659495; Tue, 15 Jul 2025 07:10:59 -0700 (PDT) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-70497d5bb30sm58184806d6.81.2025.07.15.07.10.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jul 2025 07:10:58 -0700 (PDT) Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 4B2E8F40068; Tue, 15 Jul 2025 10:10:58 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 15 Jul 2025 10:10:58 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehhedtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdortddttddvnecuhfhrohhmpeeuohhquhhnucfh vghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnhephedtfeeiveeiffehtddtuedtjedufeehheekiedtvddtgeefffdvtdeigfevgeeg necuffhomhgrihhnpehophgvnhhgrhhouhhprdhorhhgpdhruhhsthdqlhgrnhhgrdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsgho qhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieegqd dujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihm vgdrnhgrmhgvpdhnsggprhgtphhtthhopedukedpmhhouggvpehsmhhtphhouhhtpdhrtg hpthhtoheplhhoshhsihhnsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlvghvhihm ihhttghhvghllhdtsehgmhgrihhlrdgtohhmpdhrtghpthhtohepohhjvggurgeskhgvrh hnvghlrdhorhhgpdhrtghpthhtoheprghlvgigrdhgrgihnhhorhesghhmrghilhdrtgho mhdprhgtphhtthhopehgrghrhiesghgrrhihghhuohdrnhgvthdprhgtphhtthhopegsjh horhhnfegpghhhsehprhhothhonhhmrghilhdrtghomhdprhgtphhtthhopegrrdhhihhn uggsohhrgheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghlihgtvghrhihhlhesgh hoohhglhgvrdgtohhmpdhrtghpthhtohepthhmghhrohhsshesuhhmihgthhdrvgguuh X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Jul 2025 10:10:57 -0400 (EDT) Date: Tue, 15 Jul 2025 07:10:56 -0700 From: Boqun Feng To: Benno Lossin Cc: Mitchell Levy , Miguel Ojeda , Alex Gaynor , 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 Message-ID: References: <20250712-rust-percpu-v2-0-826f2567521b@gmail.com> <20250712-rust-percpu-v2-3-826f2567521b@gmail.com> <68762e19.170a0220.33e203.a0b7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: beet336jg3dtgu7f1sy76dpzqigtxgeh X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: E0B4C10000B X-Rspam-User: X-HE-Tag: 1752588660-228133 X-HE-Meta: U2FsdGVkX1/3TLdKI0mijEz2D/g9s1MyOOxdkLnrbEp/fNZo/8guTaE1EVfjO5wpFOIMSHQZdwOLlYhMumDidrxjn80s91+D71VxdiiBW7sCKaErrD5KOGl4AnzRV9uO9bGqPlSsSpaV3DMAX1hkXeDaW5490+0KkJaJ0TdHMpdVFucsOWCkSz0NDeEKEDEpRSeKQmsEbDxgm1aYEQ/j0tcdLBx8fxCR0VTiUdXNVMMWvSldut/UbybsbNX/l8QpUQc0584CKkP44dD0icA4PI+XICx7Ad9JlQiEC2ZtKlpofCXQzP5bZrcKvd6CKKMTsrPR5ByPrjexm09nFAnXyqI2M0jq4m1RF6ewRATuEDTsDQIRAMexRd+jdHluavp/8341Ft6ax/Rn3zrkuJU40LPVCFo9GCLe3RP+cUY9QP555RlC3BgcLcKprf5uuIssLg1BxJIXUkvRpUdIsDgiZgCaonj+L6JojG4V0VFGxCOHDOcvwUxgLcZ85UAhPqdkViBy+hXvveLKTybzCQdnEXVIVfj4GTxre+lEkw4A/dvLWRylFwgrmCtVaVkcZvsGdyQw0ssuTSLQfaacXaF2npYTUPBdrCRO+VxvLUNbWVqjJGCt8FaAUN3mX3reivdvKg4PuLTkfvr4Ds5h6mDrudrGUO/DXsHkDlzVNpk4VN+3J1jSbaO3D87BG1pXg5+um2n9UJEfJLOWXAUr714Lg4MT/dTTEz7vyFz8nD7n2ZKIb736zwKbRJ3ZB456Ek8wqIHxs61qBsjVovgkdcDZvOKdqx1qbsTbg5WhoE9J4yayHT9bBuSmElr6oewYgymNLkPqDO0ygA4PiL3M9jgEWrVhwDviiLLZliOi4YaAoghwr6nRmKNiINFXGXJzIMLIRbfKJAxRrOj5wUwBcxio7MI0iU1saIBLNYsXFGUEfAhTT/8ijfFqOpCg7LZ3aYVS2dJHqdWCXu1jPjzdLMC 6i6NZxR7 CmJyJROYpu5ZHExPTxdm3UXoXuJFv/1ptp3Tey67PVs2VqZZZyCuFnGc1mP5BCqIN5xcF2d+W2HemmPnDpTXqFfH5kEs5x4yXkj4/EVPgtixcKWKOoU0eKYwRRfBLDkJvSiVJBXzhNYdmQw+MbrtyZSRoYshfenrLoSW7m4VERPVMof7csnz617ZVohHSJ5EfHDA83Vg+6OVkf4PaZiH3HW4kgZRML0Pd+tzS5D0kh2WPia93LUcvTcutawHc5E5cngIVUrZMngLSXiMl5/PvAYw/BcbXrnMRvT8Vw5BotnX2ywd9yc97KOwxnet4MPcQG1M9yD8c8rBrs3ZLoRGIGaKe/CV84AU1yQjdxarxQobJ9Q1jGYagDp+f/aHNF3yh3QdJmmMi5y7ptLbC7nKxtTofAW2QnXrf0hejQMDJ78fZQYHIKdarOkfxseLdZW2fopGhQQ2aJJaOiv576xFsB99IRN401tk/YMTfm5T3aCzRY7zoGRViRbCPvCSdLPlytHIdZPuLI7I57e1tHjY2PBWVdvdoCf9a0ZwzL82jTmpR0w/e0rUtcxwZZ8N6S7Z+c0gYSvm+iNtqiyHrRMjFZqUA53nkmZrz6dSCnamEd/kgXcX+ZATp+nB4DXlGqvShXGKgOgVxDUZECShTspi11duzUg== 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, Jul 15, 2025 at 01:31:06PM +0200, Benno Lossin wrote: [...] > >> > +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 :) > > I haven't taken a look at your implementation, but you do have the type > declared in `define_per_cpu!`, so it's a bit of a mystery to me why you > can't get that out in `unsafe_get_per_cpu!`... > > Maybe in a few weeks I'll be able to take a closer look. > > >> > + // 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 First of all, `thread_local!` has to be implemented by some sys-specific unsafe mechanism, right? For example on unix, I think it's using pthread_key_t: https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html what we are implementing (or wrapping) is the very basic unsafe mechanism for percpu here. Surely we can explore the design for a safe API, but the unsafe mechanism is probably necessary to look into at first. > >> 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 This sounds reasonable to me. > >> 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.) > > What kinds of types would you like to store? Allocations? Just integers > in bigger structs? Mutexes? > In the VMBus driver, there is a percpu work_struct. > > 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? > > So I think using an API similar to `thread_local!` will allow us to have > multiple other APIs that slot into that. `Cell` for `T: Copy`, > `RefCell` for cases where you don't care about the runtime overhead, > plain `T` for cases where you only need `&T`. For the case where you > need `&mut T`, we could have something like a `TokenCell` that gives > out a token that you need to mutably borrow in order to get `&mut T`. > Finally for anything else that is too restricted by this, users can also > use `UnsafeCell` although that requires `unsafe`. > > I think the advantage of this is that the common cases are all safe and > very idiomatic. In the current design, you *always* have to use unsafe. > I agree, but like I said, we need to figure out the unsafe interface that C already uses and build API upon it. I think focusing on the unsafe mechanism may be the way to start: you cannot implement something that cannot be implemented, and we don't have the magic pthread_key here ;-) Regards, Boqun > > 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. > > It would require the same amount of unsafe & safety comments, but it > wouldn't be bigger comments, since you can just as well create `&mut T` > to the value. > > --- > Cheers, > Benno