Message ID | 20240301-rust-locks-get-mut-v5-1-c5131dbbd3c4@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-88838-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:fa17:b0:10a:f01:a869 with SMTP id ju23csp39098dyc; Fri, 1 Mar 2024 09:43:44 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWq5C4+X+7RAo5iHz3N0lDCnwv3H4FAfb70eVLb1sQmDRnz6WyLKUnVDuvtHZE3wQzQ4KUmrFi1lGgYPSyoYUrYtGOa4Q== X-Google-Smtp-Source: AGHT+IE1kFoh1W0sUfoEBYILfhH6xYCHgDxATYq+cn8GvGnraSZOw+lJEpcmkzDpI66eyOqih9d+ X-Received: by 2002:a50:8dc9:0:b0:566:115c:cc88 with SMTP id s9-20020a508dc9000000b00566115ccc88mr1727736edh.9.1709315024247; Fri, 01 Mar 2024 09:43:44 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709315024; cv=pass; d=google.com; s=arc-20160816; b=1Kc4Vl1B3Eo6gGxTQMJ1fjoVhypGfYrY43t0tK18oY1rfmSXgx5yDykoS5R3n8efkg kqNbHyh3Uhul8I1c5TiCmR39+MeS+ytFGAWbvNJSqraF/1VaweSyW6ZtP0oQy9LSO1ea X/SmW4avsJIk/bsRLK4cgcBPkIllNnXlp9ezulCm1zDMwcUzxemORjTySuF3kY2WBmFb VJDlwGEyMTP3R4iqUxIF18QKX5H+gnbFWqx3jxdukdbR19w+duZTAU1BO82Li8GlgAmY K6NbuszQsDldYslGmLj00fzyGirKjaOONkAjFKZbt5hzGL27MHUKoYW1IOVywUb+TDef cDUw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=reply-to:cc:to:message-id:content-transfer-encoding:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject:date :from:dkim-signature; bh=UK7p6MoKXfQ7xWiic4qOePsogb8wqSpASyqMbkkz1Ks=; fh=CB0SQ8NT5yK5U0PYYKMW4Mil/BHm2L7ptSfjnGifIfs=; b=G8/nvijtXyroSInpwv3De7DGGcjLYYaEEPNl531/BgSwZV/dbfSljc3CC8fQmbnRgj 5Mp6B3qz3oG0K9H5tJd9foL1FzPq3ZQZ/7AFg5wS43zTtxfc+mvTWxAyF576o2q2AI57 mvhNmOcRNEexS/5YbLjQnmxf6iYrCDl3l5bf7lL5mKLrHx/h3DomZ8VR6kdiyVoCKvjQ 3K7RRfhQLCOOxPq44W5QU80eCs3BTSrH1CboafNDZc1f8Q2sXc3jsCqC3shmuGRNh9at r/ctobKpGmOQ6ls7U5MGvDBfmCbzJD1njOs09UNaY+egKcopu8b+EDjmDu9qzY3nj1RL lV8A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ohI/dcuw"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-88838-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88838-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id o7-20020a056402038700b0056442886f79si1565069edv.259.2024.03.01.09.43.44 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 09:43:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88838-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ohI/dcuw"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-88838-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88838-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id C2A5C1F2AAA6 for <ouuuleilei@gmail.com>; Fri, 1 Mar 2024 17:34:59 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A15E339AF8; Fri, 1 Mar 2024 17:33:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ohI/dcuw" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7C9E46B3; Fri, 1 Mar 2024 17:33:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709314409; cv=none; b=GW9ZuZj8ktvG0s6/LUkeKHADvn8/Y7/mPwLAVEC5XJZdVMeZQMmrtlNshmrRm5wpeElNNVSRKdHDZVkZmwbpFY7pFQi9QknhQEX467htk0p0gzG9IlraZurUHxBqRh3ABgLBzV/cvKN6d0XPxkaWZy1HOASMYsW2qfuG7a0cTyA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709314409; c=relaxed/simple; bh=IYsBs/BhF0iz0VJZYgI9tkngj+zz1RnNDtdkOfgCrfU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=lsgUVe844TUH0cxP9Z0EuIEeWsCW9uHL1K3F/nfM0jBXbS3rqXH9gvpwvLiRTLPQgzub94LzzTP6EqmgAhWSy1vi5L+nBm8qPzyOXq0zkRxvMLQMW9bVMAUnyknxCh8tBGGb4Aua/wqNsH+peHSZovvhp/ZSM/TnoEdQ2GDGSUk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ohI/dcuw; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPS id 29683C433F1; Fri, 1 Mar 2024 17:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709314409; bh=IYsBs/BhF0iz0VJZYgI9tkngj+zz1RnNDtdkOfgCrfU=; h=From:Date:Subject:To:Cc:Reply-To:From; b=ohI/dcuwZZ8j8UU5LDwFfoF/l4sfTNfbRCxGn7UllwL66Rc8ZJtrL6bo8W/19jDfH jBRh2AufqQjOAqYdkOzXQfxvERgNTD/xn4/V9jJOSl/RS+rBIKmf71lq2WhBC13UBK r9UmnijYyGhfZ1V+2kK7ZOkYLumV0oUZYcTxhQWR1VpVNBtTMJ36ZX0QwJyttkbJHk rPjczjYzmX9h9XC07rEyqzaHjEjMosZ1IYhh8N7mMDy6WyHm6SVIJ2pe4pLvKhQgLH pnXqN3oLIsMUk/8blYwAbAfUZ/eaVYjNkVS75oLjmwe9i/OO/s166VVLK7j1ys76L6 3UvFDUYeqatyQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1460AC5475B; Fri, 1 Mar 2024 17:33:29 +0000 (UTC) From: Mathys-Gasnier via B4 Relay <devnull+mathys35.gasnier.gmail.com@kernel.org> Date: Fri, 01 Mar 2024 18:33:23 +0100 Subject: [PATCH v5] rust: locks: Add `get_mut` method to `Lock` Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240301-rust-locks-get-mut-v5-1-c5131dbbd3c4@gmail.com> X-B4-Tracking: v=1; b=H4sIAGIR4mUC/23NQQ6CMBCF4auYrq3pTItFV97DuCjTARsFTItEY 7i7VTfEsPxfMt+8ROIYOIn96iUijyGFvstRrFeCzq5rWAafW6BCowBKGe9pkNeeLkk2PMj2Pkg yqCyCAm+dyIe3yHV4fNHjKfc5pKGPz++PET7rj0O1W+JGkCCJdQE1ac/GHprWheuG+lZ8uBFnB OAigZkoiLw2hJVV1T+hZwQuEzoTXpduW5vKs/b/hJkT20XCZAKNq+rCWmVdOSemaXoDEqxKv30 BAAA= To: Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>, =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, Benno Lossin <benno.lossin@proton.me>, Andreas Hindborg <a.hindborg@samsung.com>, Alice Ryhl <aliceryhl@google.com> Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Martin Rodriguez Reboredo <yakoyoku@gmail.com>, Mathys-Gasnier <mathys35.gasnier@gmail.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=ed25519-sha256; t=1709314408; l=3361; i=mathys35.gasnier@gmail.com; s=20240118; h=from:subject:message-id; bh=YgqZEuEg7qPEU8LNGXge52fKNIIVVzwOHPlT4tjNiao=; b=L+sGaDcR7Vjd5mjM+tfqElKX2By5PtqYuLSS2MnvAbyQwx6h3pfgD5m/D0VbWzmKEhmdgVaU8 gTFLD+1PsWVCUM/0nezEu0MMtJPvv60XtMhOs7USiOCY7eJd7RPfLpx X-Developer-Key: i=mathys35.gasnier@gmail.com; a=ed25519; pk=C5tqKAA3Ua7li5s3a+q2aDelT2j98/yjGg2nEVGArXE= X-Endpoint-Received: by B4 Relay for mathys35.gasnier@gmail.com/20240118 with auth_id=129 X-Original-From: Mathys-Gasnier <mathys35.gasnier@gmail.com> Reply-To: <mathys35.gasnier@gmail.com> X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792346710856007364 X-GMAIL-MSGID: 1792346710856007364 |
Series |
[v5] rust: locks: Add `get_mut` method to `Lock`
|
|
Commit Message
Mathys-Gasnier via B4 Relay
March 1, 2024, 5:33 p.m. UTC
From: Mathys-Gasnier <mathys35.gasnier@gmail.com> Having a mutable reference guarantees that no other threads have access to the lock, so we can take advantage of that to grant callers access to the protected data without the cost of acquiring and releasing the locks. Since the lifetime of the data is tied to the mutable reference, the borrow checker guarantees that the usage is safe. Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Mathys-Gasnier <mathys35.gasnier@gmail.com> --- Changes in v5: - Adding example - Link to v4: https://lore.kernel.org/r/20240226-rust-locks-get-mut-v4-1-24abf57707a8@gmail.com Changes in v4: - Improved documentation - Link to v3: https://lore.kernel.org/r/20240222-rust-locks-get-mut-v3-1-d38a6f4bde3d@gmail.com Changes in v3: - Changing the function to take a `Pin<&mut self>` instead of a `&mut self` - Removed reviewed-by's since big changes were made. Please take another look. - Link to v2: https://lore.kernel.org/r/20240212-rust-locks-get-mut-v2-1-5ccd34c2b70b@gmail.com Changes in v2: - Improved doc comment. - Link to v1: https://lore.kernel.org/r/20240209-rust-locks-get-mut-v1-1-ce351fc3de47@gmail.com --- rust/kernel/sync/lock.rs | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) --- base-commit: 711cbfc717650532624ca9f56fbaf191bed56e67 change-id: 20240118-rust-locks-get-mut-c42072101d7a Best regards,
Comments
On Fri, Mar 01, 2024 at 06:33:23PM +0100, Mathys-Gasnier via B4 Relay wrote: > From: Mathys-Gasnier <mathys35.gasnier@gmail.com> > > Having a mutable reference guarantees that no other threads have > access to the lock, so we can take advantage of that to grant callers > access to the protected data without the cost of acquiring and > releasing the locks. Since the lifetime of the data is tied to the > mutable reference, the borrow checker guarantees that the usage is safe. > > Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> > Reviewed-by: Alice Ryhl <aliceryhl@google.com> > Reviewed-by: Boqun Feng <boqun.feng@gmail.com> > Signed-off-by: Mathys-Gasnier <mathys35.gasnier@gmail.com> > --- > Changes in v5: > - Adding example > - Link to v4: https://lore.kernel.org/r/20240226-rust-locks-get-mut-v4-1-24abf57707a8@gmail.com > > Changes in v4: > - Improved documentation > - Link to v3: https://lore.kernel.org/r/20240222-rust-locks-get-mut-v3-1-d38a6f4bde3d@gmail.com > > Changes in v3: > - Changing the function to take a `Pin<&mut self>` instead of a `&mut self` > - Removed reviewed-by's since big changes were made. Please take another > look. > - Link to v2: https://lore.kernel.org/r/20240212-rust-locks-get-mut-v2-1-5ccd34c2b70b@gmail.com > > Changes in v2: > - Improved doc comment. > - Link to v1: https://lore.kernel.org/r/20240209-rust-locks-get-mut-v1-1-ce351fc3de47@gmail.com > --- > rust/kernel/sync/lock.rs | 38 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 37 insertions(+), 1 deletion(-) > > diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs > index f12a684bc957..345ca7be9d9f 100644 > --- a/rust/kernel/sync/lock.rs > +++ b/rust/kernel/sync/lock.rs > @@ -7,7 +7,11 @@ > > use super::LockClassKey; > use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque, types::ScopeGuard}; > -use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned}; > +use core::{ > + cell::UnsafeCell, > + marker::{PhantomData, PhantomPinned}, > + pin::Pin, > +}; > use macros::pin_data; > > pub mod mutex; > @@ -121,6 +125,38 @@ pub fn lock(&self) -> Guard<'_, T, B> { > // SAFETY: The lock was just acquired. > unsafe { Guard::new(self, state) } > } > + > + /// Gets the data contained in the lock. > + /// > + /// Having a mutable reference to the lock guarantees that no other threads have access to the > + /// lock. And because `data` is not structurally pinned, it is safe to get a mutable reference > + /// to the lock content. > + /// > + /// # Example > + /// Thanks! But please see below: > + /// Using `get_mut` with a mutex. > + /// > + /// ``` The example looks good, however, I was thinking about something like: /// ``` /// use kernel::sync::{new_mutex, Mutex}; /// /// let mut m = Box::pin_init(new_mutex!(None))?; /// /// assert_eq!(*(m.lock()), None); /// /// Mutex::get_mut(m.as_mut()).replace(42i32); /// /// assert_eq!(*(m.lock()), Some(42)); /// /// # Ok::<(), Error>(()) /// ``` because, this will also run something instead of just compiling a function. > + /// use kernel::sync::Mutex; > + /// > + /// struct Example { > + /// a: u32, > + /// b: u32, > + /// } > + /// > + /// fn example(m: Pin<&mut Mutex<Example>>) { > + /// // Calling from Mutex to avoid conflict with Pin::get_mut(). > + /// let mut data = Mutex::get_mut(m); The other thing I notice when I try to make the above example work is: `Pin` also has a `get_mut`[1] function, so seems we have to use `Mutex::get_mut` to invoke the correct function, I personally want the following just works: m.as_mut().get_mut().replace(42i32); and looks to me the simplest way is to change the function's name (for example `get_data_mut`), and we can do: m.as_mut().get_data_mut().replace(42i32); Thoughts? Regards, Boqun [1]: https://doc.rust-lang.org/core/pin/struct.Pin.html#method.get_mut > + /// data.a += 10; > + /// data.b += 20; > + /// } > + /// ``` > + pub fn get_mut(self: Pin<&mut Self>) -> &mut T { > + // SAFETY: The lock will only be used to get a reference to the data, therefore self won't > + // get moved. > + let lock = unsafe { self.get_unchecked_mut() }; > + lock.data.get_mut() > + } > } > > /// A lock guard. > > --- > base-commit: 711cbfc717650532624ca9f56fbaf191bed56e67 > change-id: 20240118-rust-locks-get-mut-c42072101d7a > > Best regards, > -- > Mathys-Gasnier <mathys35.gasnier@gmail.com> > >
Le ven. 1 mars 2024 à 23:53, Boqun Feng <boqun.feng@gmail.com> a écrit : > > On Fri, Mar 01, 2024 at 06:33:23PM +0100, Mathys-Gasnier via B4 Relay wrote: > > From: Mathys-Gasnier <mathys35.gasnier@gmail.com> > > > > Having a mutable reference guarantees that no other threads have > > access to the lock, so we can take advantage of that to grant callers > > access to the protected data without the cost of acquiring and > > releasing the locks. Since the lifetime of the data is tied to the > > mutable reference, the borrow checker guarantees that the usage is safe. > > > > Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> > > Reviewed-by: Alice Ryhl <aliceryhl@google.com> > > Reviewed-by: Boqun Feng <boqun.feng@gmail.com> > > Signed-off-by: Mathys-Gasnier <mathys35.gasnier@gmail.com> > > --- > > Changes in v5: > > - Adding example > > - Link to v4: https://lore.kernel.org/r/20240226-rust-locks-get-mut-v4-1-24abf57707a8@gmail.com > > > > Changes in v4: > > - Improved documentation > > - Link to v3: https://lore.kernel.org/r/20240222-rust-locks-get-mut-v3-1-d38a6f4bde3d@gmail.com > > > > Changes in v3: > > - Changing the function to take a `Pin<&mut self>` instead of a `&mut self` > > - Removed reviewed-by's since big changes were made. Please take another > > look. > > - Link to v2: https://lore.kernel.org/r/20240212-rust-locks-get-mut-v2-1-5ccd34c2b70b@gmail.com > > > > Changes in v2: > > - Improved doc comment. > > - Link to v1: https://lore.kernel.org/r/20240209-rust-locks-get-mut-v1-1-ce351fc3de47@gmail.com > > --- > > rust/kernel/sync/lock.rs | 38 +++++++++++++++++++++++++++++++++++++- > > 1 file changed, 37 insertions(+), 1 deletion(-) > > > > diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs > > index f12a684bc957..345ca7be9d9f 100644 > > --- a/rust/kernel/sync/lock.rs > > +++ b/rust/kernel/sync/lock.rs > > @@ -7,7 +7,11 @@ > > > > use super::LockClassKey; > > use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque, types::ScopeGuard}; > > -use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned}; > > +use core::{ > > + cell::UnsafeCell, > > + marker::{PhantomData, PhantomPinned}, > > + pin::Pin, > > +}; > > use macros::pin_data; > > > > pub mod mutex; > > @@ -121,6 +125,38 @@ pub fn lock(&self) -> Guard<'_, T, B> { > > // SAFETY: The lock was just acquired. > > unsafe { Guard::new(self, state) } > > } > > + > > + /// Gets the data contained in the lock. > > + /// > > + /// Having a mutable reference to the lock guarantees that no other threads have access to the > > + /// lock. And because `data` is not structurally pinned, it is safe to get a mutable reference > > + /// to the lock content. > > + /// > > + /// # Example > > + /// > > Thanks! But please see below: > > > + /// Using `get_mut` with a mutex. > > + /// > > + /// ``` > > The example looks good, however, I was thinking about something like: > > /// ``` > /// use kernel::sync::{new_mutex, Mutex}; > /// > /// let mut m = Box::pin_init(new_mutex!(None))?; > /// > /// assert_eq!(*(m.lock()), None); > /// > /// Mutex::get_mut(m.as_mut()).replace(42i32); > /// > /// assert_eq!(*(m.lock()), Some(42)); > /// > /// # Ok::<(), Error>(()) > /// ``` > > because, this will also run something instead of just compiling a > function. > > > + /// use kernel::sync::Mutex; > > + /// > > + /// struct Example { > > + /// a: u32, > > + /// b: u32, > > + /// } > > + /// > > + /// fn example(m: Pin<&mut Mutex<Example>>) { > > + /// // Calling from Mutex to avoid conflict with Pin::get_mut(). > > + /// let mut data = Mutex::get_mut(m); > > The other thing I notice when I try to make the above example work is: > `Pin` also has a `get_mut`[1] function, so seems we have to use > `Mutex::get_mut` to invoke the correct function, I personally want the > following just works: > > m.as_mut().get_mut().replace(42i32); > > and looks to me the simplest way is to change the function's name (for > example `get_data_mut`), and we can do: > > m.as_mut().get_data_mut().replace(42i32); > > Thoughts? I don't understand why `Pin::get_mut` creates a conflict as it should be behind a where close forcing the type to be `UnPin`. The name of the function was chosen to be the same as rust std `Mutex::get_mut` [1], but you are right renaming this to something else might be the easiest way of fixing it Regards, Mathys Gasnier [1]: https://doc.rust-lang.org/std/sync/struct.Mutex.html#method.get_mut > Regards, > Boqun > > > [1]: https://doc.rust-lang.org/core/pin/struct.Pin.html#method.get_mut > > > > > + /// data.a += 10; > > + /// data.b += 20; > > + /// } > > + /// ``` > > + pub fn get_mut(self: Pin<&mut Self>) -> &mut T { > > + // SAFETY: The lock will only be used to get a reference to the data, therefore self won't > > + // get moved. > > + let lock = unsafe { self.get_unchecked_mut() }; > > + lock.data.get_mut() > > + } > > } > > > > /// A lock guard. > > > > --- > > base-commit: 711cbfc717650532624ca9f56fbaf191bed56e67 > > change-id: 20240118-rust-locks-get-mut-c42072101d7a > > > > Best regards, > > -- > > Mathys-Gasnier <mathys35.gasnier@gmail.com> > > > > Le ven. 1 mars 2024 à 23:53, Boqun Feng <boqun.feng@gmail.com> a écrit : > > On Fri, Mar 01, 2024 at 06:33:23PM +0100, Mathys-Gasnier via B4 Relay wrote: > > From: Mathys-Gasnier <mathys35.gasnier@gmail.com> > > > > Having a mutable reference guarantees that no other threads have > > access to the lock, so we can take advantage of that to grant callers > > access to the protected data without the cost of acquiring and > > releasing the locks. Since the lifetime of the data is tied to the > > mutable reference, the borrow checker guarantees that the usage is safe. > > > > Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> > > Reviewed-by: Alice Ryhl <aliceryhl@google.com> > > Reviewed-by: Boqun Feng <boqun.feng@gmail.com> > > Signed-off-by: Mathys-Gasnier <mathys35.gasnier@gmail.com> > > --- > > Changes in v5: > > - Adding example > > - Link to v4: https://lore.kernel.org/r/20240226-rust-locks-get-mut-v4-1-24abf57707a8@gmail.com > > > > Changes in v4: > > - Improved documentation > > - Link to v3: https://lore.kernel.org/r/20240222-rust-locks-get-mut-v3-1-d38a6f4bde3d@gmail.com > > > > Changes in v3: > > - Changing the function to take a `Pin<&mut self>` instead of a `&mut self` > > - Removed reviewed-by's since big changes were made. Please take another > > look. > > - Link to v2: https://lore.kernel.org/r/20240212-rust-locks-get-mut-v2-1-5ccd34c2b70b@gmail.com > > > > Changes in v2: > > - Improved doc comment. > > - Link to v1: https://lore.kernel.org/r/20240209-rust-locks-get-mut-v1-1-ce351fc3de47@gmail.com > > --- > > rust/kernel/sync/lock.rs | 38 +++++++++++++++++++++++++++++++++++++- > > 1 file changed, 37 insertions(+), 1 deletion(-) > > > > diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs > > index f12a684bc957..345ca7be9d9f 100644 > > --- a/rust/kernel/sync/lock.rs > > +++ b/rust/kernel/sync/lock.rs > > @@ -7,7 +7,11 @@ > > > > use super::LockClassKey; > > use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque, types::ScopeGuard}; > > -use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned}; > > +use core::{ > > + cell::UnsafeCell, > > + marker::{PhantomData, PhantomPinned}, > > + pin::Pin, > > +}; > > use macros::pin_data; > > > > pub mod mutex; > > @@ -121,6 +125,38 @@ pub fn lock(&self) -> Guard<'_, T, B> { > > // SAFETY: The lock was just acquired. > > unsafe { Guard::new(self, state) } > > } > > + > > + /// Gets the data contained in the lock. > > + /// > > + /// Having a mutable reference to the lock guarantees that no other threads have access to the > > + /// lock. And because `data` is not structurally pinned, it is safe to get a mutable reference > > + /// to the lock content. > > + /// > > + /// # Example > > + /// > > Thanks! But please see below: > > > + /// Using `get_mut` with a mutex. > > + /// > > + /// ``` > > The example looks good, however, I was thinking about something like: > > /// ``` > /// use kernel::sync::{new_mutex, Mutex}; > /// > /// let mut m = Box::pin_init(new_mutex!(None))?; > /// > /// assert_eq!(*(m.lock()), None); > /// > /// Mutex::get_mut(m.as_mut()).replace(42i32); > /// > /// assert_eq!(*(m.lock()), Some(42)); > /// > /// # Ok::<(), Error>(()) > /// ``` > > because, this will also run something instead of just compiling a > function. > > > + /// use kernel::sync::Mutex; > > + /// > > + /// struct Example { > > + /// a: u32, > > + /// b: u32, > > + /// } > > + /// > > + /// fn example(m: Pin<&mut Mutex<Example>>) { > > + /// // Calling from Mutex to avoid conflict with Pin::get_mut(). > > + /// let mut data = Mutex::get_mut(m); > > The other thing I notice when I try to make the above example work is: > `Pin` also has a `get_mut`[1] function, so seems we have to use > `Mutex::get_mut` to invoke the correct function, I personally want the > following just works: > > m.as_mut().get_mut().replace(42i32); > > and looks to me the simplest way is to change the function's name (for > example `get_data_mut`), and we can do: > > m.as_mut().get_data_mut().replace(42i32); > > Thoughts? > > Regards, > Boqun > > > [1]: https://doc.rust-lang.org/core/pin/struct.Pin.html#method.get_mut > > > > > + /// data.a += 10; > > + /// data.b += 20; > > + /// } > > + /// ``` > > + pub fn get_mut(self: Pin<&mut Self>) -> &mut T { > > + // SAFETY: The lock will only be used to get a reference to the data, therefore self won't > > + // get moved. > > + let lock = unsafe { self.get_unchecked_mut() }; > > + lock.data.get_mut() > > + } > > } > > > > /// A lock guard. > > > > --- > > base-commit: 711cbfc717650532624ca9f56fbaf191bed56e67 > > change-id: 20240118-rust-locks-get-mut-c42072101d7a > > > > Best regards, > > -- > > Mathys-Gasnier <mathys35.gasnier@gmail.com> > > > >
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs index f12a684bc957..345ca7be9d9f 100644 --- a/rust/kernel/sync/lock.rs +++ b/rust/kernel/sync/lock.rs @@ -7,7 +7,11 @@ use super::LockClassKey; use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque, types::ScopeGuard}; -use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned}; +use core::{ + cell::UnsafeCell, + marker::{PhantomData, PhantomPinned}, + pin::Pin, +}; use macros::pin_data; pub mod mutex; @@ -121,6 +125,38 @@ pub fn lock(&self) -> Guard<'_, T, B> { // SAFETY: The lock was just acquired. unsafe { Guard::new(self, state) } } + + /// Gets the data contained in the lock. + /// + /// Having a mutable reference to the lock guarantees that no other threads have access to the + /// lock. And because `data` is not structurally pinned, it is safe to get a mutable reference + /// to the lock content. + /// + /// # Example + /// + /// Using `get_mut` with a mutex. + /// + /// ``` + /// use kernel::sync::Mutex; + /// + /// struct Example { + /// a: u32, + /// b: u32, + /// } + /// + /// fn example(m: Pin<&mut Mutex<Example>>) { + /// // Calling from Mutex to avoid conflict with Pin::get_mut(). + /// let mut data = Mutex::get_mut(m); + /// data.a += 10; + /// data.b += 20; + /// } + /// ``` + pub fn get_mut(self: Pin<&mut Self>) -> &mut T { + // SAFETY: The lock will only be used to get a reference to the data, therefore self won't + // get moved. + let lock = unsafe { self.get_unchecked_mut() }; + lock.data.get_mut() + } } /// A lock guard.