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 56E0CE77188 for ; Sat, 4 Jan 2025 22:45:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BFA76B0082; Sat, 4 Jan 2025 17:45:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 548F36B0088; Sat, 4 Jan 2025 17:45:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E96B6B0089; Sat, 4 Jan 2025 17:45:49 -0500 (EST) 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 1C8CC6B0082 for ; Sat, 4 Jan 2025 17:45:49 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8865BC0F5D for ; Sat, 4 Jan 2025 22:45:48 +0000 (UTC) X-FDA: 82971253176.21.CB950B1 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id E07A540008 for ; Sat, 4 Jan 2025 22:45:46 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="L/WI3oWD"; spf=pass (imf04.hostedemail.com: domain of dennis@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dennis@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736030747; 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=K5/UrjWPPLWiKsVNmznvvw47ovs0JIs92qSQIfb5DWQ=; b=fAggJiTEcC2zTlVksHAiFjSTro1HhIPoqwqYFkRPyVnWHugZcpNAkmsLnchcHykRs2x//b /dcSdxevrYX8EBjsDa5oQ2a7z0+3Byc/g0ihHB/kG2lFsK1YN9vXrnwCZ2fGAH3i6/E2Y9 /mwdoed74bGbItPYGwDsmIf5hkS+c5w= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="L/WI3oWD"; spf=pass (imf04.hostedemail.com: domain of dennis@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dennis@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736030747; a=rsa-sha256; cv=none; b=EP8ZuvjY/Kx1bvcAPqYkcb3AuworZsqpHL3+Kafv4TrzRBANt/1Nz8FRkCIawdJcuYBt6Z hTf+ZuoMcAKo+DP7Q926PCLYPN+oayAWEMNV9nNZbL1W1SprDTpw4EPmTBNPxki0xzOxm/ +GzvD5RsEdYO8LThWM9VVwJ1vP2X2B8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 14963A40A96; Sat, 4 Jan 2025 22:43:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0D5EC4CED1; Sat, 4 Jan 2025 22:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736030745; bh=qcikyWA15fK9jdBCh80Yq9BvRwwiqyehSTsW3NvssKs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L/WI3oWDvpZWLEyBQbkoPBDqcHATTTQ86J0pcl3eVqlKXhL/hL6KMSkFBOn2YK7PF muZW+Y1GYRcERr64WCHmQw8lhvsY15hqmv7XkltCGItWViZ37FIINN8tcmxAPPrfzK GVl+y8XQGBaSz5uPQsUgWXoNKm75JsM3nM7srphHXu1Mt6u3GeLiKyZQo2RrB57cmp HY8vKx6gN4M9Lc1owUnEFMX8jxh1diK49R06AbEvrW7nvP0uAJMncXkIFC8qEp33q4 Gecdqw+GfP2me5KZmosG2WxqtdjeD7st6KFm+4DBJ9LXXciYB4mQuPPr9FEz6UIQ/I lDSzHVqvRnyrA== Date: Sat, 4 Jan 2025 14:45:43 -0800 From: Dennis Zhou To: Mitchell Levy , Hudson Ayres Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Andrew Morton , Tejun Heo , Christoph Lameter , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 0/3] rust: Add Per-CPU Variable API Message-ID: References: <20241219-rust-percpu-v1-0-209117e822b1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241219-rust-percpu-v1-0-209117e822b1@gmail.com> X-Rspamd-Queue-Id: E07A540008 X-Stat-Signature: ny3uz9bqr1s546huq7aoiyxm13muqm9q X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736030746-135439 X-HE-Meta: U2FsdGVkX1/zr6pu7g7tDwM2gBVynTUhaELTLCXXDzLtKhBh9pE0O0iQUO/Cpfew16pCOhQb9niORb5RUBgMtoGrSuGBEXdvF3CYh6uhyrN0no2rhKSD1Df6IGZCXNIFky++a2ebR/vw2vaurVr6BI7E2kB7/0ywZpZ8MR9clvUccgJgKNSBWb50hw/arg+BuY1onWRVbnRrzdQ6IzwO3cE40YIdb6gTq76HNUt32fl0emNcPvTPO3NvCABAqGqazjICCJfNGMzyJiXnm3ARPh4+ihJLjQ/qXK4A0PZ9p1CkuErCy0+jpgVqdeqmaQ9YOxW1WfVfmPqQeV2ZyaN5Fs2PGPII/VekG8//0vPyW2Spk7Vy41VIGHJMv4TEAbM28SZsD6Rd6W9dR8fmMnu0xciEDrjrIX/xyCYNbtHE9uVws2k7I06q/D6gxEGz4EmNfkV1uY0mSZNqyssUvcOIAugG9Vk+3GJuJu2gfGtCPDHNXDhYDlR9uasZkY4Uzhe4ZBW7MNqFPJiMyLqiggTDW3j6GC/qhi2zrVrpakxJJosXYPSNmqgDff1tjI3ZKlVvCB2leDt5BS7P1KxkGrHMDKPhqoS9Nua4ZLpFFXPZ63uJHBb0h0YJzXUOFrGVxt3iSrtEIJFTsDxrZsQiuoPRie7sMU1vfKYTSXLS8kRK2AT5r28BzMFTOMz1u5/U4ZSw9bUVLsN2c1Afsa7g5MjKcodFc6bVqFaHYopKCT7Tw/7OXk11n5PYQYteloTCuZETf6rgQM7Bf6MCwFuDn0p+wPsms6iqODoeTpxvfKtG0KxBNLr8G+J2+pcHNLcqJFlgabs4BsFKwFdoZALwHv+WzZJrBmg7hRKJCsASSDMRiDV1xj/GXdlYrEErnUDXLAKB7hh/2wdNKEH55qe7tq7D4tVRx4baYMfspCBjJFVKZe2ciep4WPeYfJxGLRL3dkV4BnKQf4XgPIJGPYQVm9C kEjDk9mn eRI8g6J5lWWBuk7LEhpUZaR9JSV9O0tq23c8popofxYM7piS7NZayHuew0NsgNKlP8c3Yrv2+vH0lViQOWZyY0w8tECQzYY+JOL1PQCHTt3LGUQPelNnYEzoYv7y1YGf47yTPWF4e6WYpqJ0RD3nBYYsbl9wc8pVJ3NlBisaKq4QAfSySAXk1Kr9RglW7TYQ7pWxNFSeYN0auHp8eHcidHdZcAp8PwwwyIQtMsnotP3shCpOGAH6YNOmppvslYAoGnn0trKm6xYvaBlAlIrwpf/zXklOSJ84wGhEh2YHZG/lIO+6oX3MuzMbQ1p6YC7ebqN3H06wYyKzJCPiNcVSTGANVT9Hj15q2L9hj X-Bogosity: Ham, tests=bogofilter, spamicity=0.422821, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hello, On Thu, Dec 19, 2024 at 01:08:25PM -0800, Mitchell Levy wrote: > This series adds an API for declaring an using per-CPU variables from > Rust, and it also adds support for Rust access to C per-CPU variables > (subject to some soundness requirements). It also adds a small test > module, lib/percpu_test_rust.rs, in the vein of lib/percpu_test.c. > > --- > I am sending this patch as an RFC to gather feedback on the API as well > as get some input on correctness. In particular, the unsafe getter macro > is somewhat cumbersome, though its safety requirements for pure-Rust > code aren't too difficult to verify (interoperation with C code is > certainly much more tricky). > I've been thinking a little bit about this over the holidays and fwiw am not really the right person to evaluate the rust side of this. I did briefly discuss this with Hudson (cced) who is more familiar with rust. In addition to Christoph's comments: 1. This implementation seems targeted at static allocations and the safety of this api relies on the end user doing the right thing. There are many percpu variables created dynamically via alloc_percpu() and the lifetime of those variables are tied to a larger object. So access to those variables is safe via the understanding the larger object exists. I feel like there is room here for rust to do this checking somehow? Maybe in rust-only percpu variables, but something better nonetheless. 2. As Christoph mentioned, the percpu api relies heavily on macros for architecture specific optimizations. Your implementation seems asm-generic correct, but we should find a way to export the architecture specific percpu macros. `this_cpu_off` is a percpu variable that helps x86 `arch_raw_cpu_ptr()`. 3. Maybe a good use case to start off with would be percpu_refcount and how rust can use it or how it can make something like that safer? Some of Hudson's direct comments about the Rust implementation: 1. DerefMut for PerCpuRef is ultimately constructing a reference from a raw integer without preserving the provenance of the original pointer in any way (since this integer is being constructed from raw register reads). I believe this violates Rust's pointer provenance rules for unsafe code. 2. The safety requirements of unsafe_get_per_cpu_ref seem like they would often not be possible to verify at the callsite of the macro without global knowledge -- especially for percpu variables defined in C code. Is this a misunderstanding? Can you show an example of where it would be straightforward to build a higher-level safe API on top of this unsafe one? > It was suggested that I base my implementation on Rust's thread-local > storage API. However, this API requires that for a thread-local T, any > particular usage must be via a &T. Thus, many times it is required that > thread-local variables be in the form RefCell or Cell. This has > some pretty severe disadvantages in the context of per-CPU variables. > Namely, RefCell may panic if .borrow_mut is called multiple times at > different points in the call stack. This is similar to the problem > inherent in my current implementation (that is, unsafe_get_per_cpu_ref > must be used carefully so as to not create aliasing mut references), but > this implementation flags this potential problem via an unsafe block and > the resulting PerCpuRef can be easily passed along and used fairly > easily. Cell on the other hand requires a copy any time the > underlying value is used, which is entirely avoided here. > > Signed-off-by: Mitchell Levy > I think this is a cool topic and has helped inspire me to learn a bit more rust. Hopefully I can be more helpful in the future. Thanks, Dennis