From nobody Sun Oct 5 17:57:52 2025 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 396C82DECB9; Wed, 30 Jul 2025 17:15:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753895711; cv=none; b=teG5mQ6W47V1b01q/kSnZ7UacjQjYw1bm/BW3Zty/UigFbyYGVPiY0wvcBvXfqpPCzN4Y5ENcb+M0fLicyZr4TgrUpeDln/LDkkaeFIsxzAsUvqX3w07E1Blq71EQIA3ofvMCNTgSm0lKFO7j5Vl4/BTzJ/d3kzT7yCeKpkZ27w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753895711; c=relaxed/simple; bh=s+sx+hOclSZjyk1wL29+d+rxmeuUWcBNu0h4lfKEe88=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=uS7yUrjgHhc9T+s4waRnTUeK0zrKl0wV62nZ07z70iYL4dAmqjAJWtAkwhttg/A37ghtSsqJueCFVKngO+zngx14JeZ4aPGlwl7Di492xZmFphXUCY1/HEHRTHlfclECswxUCvJ15XiCbsKwakbsliUjD4qZ0R4lNZJElfr7LJs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=jcDi7oVG; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="jcDi7oVG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1753895707; bh=s+sx+hOclSZjyk1wL29+d+rxmeuUWcBNu0h4lfKEe88=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=jcDi7oVGc+WysbOnMe1u9dnWyB9WedNAZUKfLdGc9khdr0+XV48iUiYi8RPH0LQr8 65iQNijBMZu4/1gYTU9Kg+pofKT+s2snC4wo2ReyB0U/FQl6vezRztmPZ+sukDzndv 8fD7FM3IiXtZXEo9erBbnjuynDPXP70F90sa7figEsbi5KsLu/Omkp7fJpYI/05I9G bzuSDB/SKWCkIZhNRbOIkMhJUhf6i3mjwU68kw6TOaxPYWpgfbnNVLM7neAFgPDojR ELh9gl+5XRDxGApRCRNS/Epk+wW3TiCJdlIYjGGByb+8E+4tU0tUpVepYflf7C/DfY /FjeHVsff0AYg== Received: from [192.168.0.7] (unknown [IPv6:2804:14d:72b4:82f6:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id E3B2017E130E; Wed, 30 Jul 2025 19:15:04 +0200 (CEST) From: Daniel Almeida Date: Wed, 30 Jul 2025 14:14:44 -0300 Subject: [PATCH 1/3] rust: lock: pin the inner data Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250730-lock-t-when-t-is-pinned-v1-1-1b97d5f28aa2@collabora.com> References: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com> In-Reply-To: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com> To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Miguel Ojeda , Alex Gaynor , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Daniel Almeida X-Mailer: b4 0.14.2 In preparation to support Lock where T is pinned, the first thing that needs to be done is to structurally pin the 'data' member. This switches the 't' parameter in Lock::new() to take in an impl PinInit instead of a plain T. This in turn uses the blanket implementation "impl PinInit for T". Subsequent patches will touch on Guard. Link: https://github.com/Rust-for-Linux/linux/issues/1181 Suggested-by: Benno Lossin Suggested-by: Boqun Feng Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl Reviewed-by: Benno Lossin --- rust/kernel/sync/lock.rs | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs index e82fa5be289c169b0c9cfe277e15988958563430..9715463cbab867a2cf59e75f030= 01d75e91bd7b6 100644 --- a/rust/kernel/sync/lock.rs +++ b/rust/kernel/sync/lock.rs @@ -11,7 +11,7 @@ types::{NotThreadSafe, Opaque, ScopeGuard}, }; use core::{cell::UnsafeCell, marker::PhantomPinned, pin::Pin}; -use pin_init::{pin_data, pin_init, PinInit}; +use pin_init::{pin_data, pin_init, PinInit, Wrapper}; =20 pub mod mutex; pub mod spinlock; @@ -115,6 +115,7 @@ pub struct Lock { _pin: PhantomPinned, =20 /// The data protected by the lock. + #[pin] pub(crate) data: UnsafeCell, } =20 @@ -127,9 +128,13 @@ unsafe impl Sync for Loc= k {} =20 impl Lock { /// Constructs a new lock initialiser. - pub fn new(t: T, name: &'static CStr, key: Pin<&'static LockClassKey>)= -> impl PinInit { + pub fn new( + t: impl PinInit, + name: &'static CStr, + key: Pin<&'static LockClassKey>, + ) -> impl PinInit { pin_init!(Self { - data: UnsafeCell::new(t), + data <- UnsafeCell::pin_init(t), _pin: PhantomPinned, // SAFETY: `slot` is valid while the closure is called and bot= h `name` and `key` have // static lifetimes so they live indefinitely. --=20 2.50.1 From nobody Sun Oct 5 17:57:52 2025 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 5524A2DFF18; Wed, 30 Jul 2025 17:15:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753895714; cv=none; b=qCzRS7x3QFQVwShJ3Kh9bhgWcVdvvXACrBYnAejYfhl/B0mGJjYy1VRtK7/uefw8c4BeAlJ4GNLga8u09a2Lh/M6QzejfrZw4K10XVUEKTluN23gSJPMEjR0Mix+FXJE8iZXFZu8Oo7SoAZG5vus6vruLfHLC2RwMTChMZ8cv1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753895714; c=relaxed/simple; bh=AXjI2AESniRBTjvjKjfF5GSYUGIK6NML1d8W4I6I+8s=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=iqqd5naZJuqlpjY/cyyGHCXECTSXg3Hjia27T0oOxdBPG7TcxTXHDiaHHTTbeYRdtYq3sPtgie3UoNpECFWaz/VQCCWHcYfMfyFVqwSeIPP0/b4svoYWenNUl5MvHi644AXt+PY0Fk4rSHuapl1LfGxiQCHZb5ArteBotKNtgTs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=ZlQGVQFp; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="ZlQGVQFp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1753895710; bh=AXjI2AESniRBTjvjKjfF5GSYUGIK6NML1d8W4I6I+8s=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ZlQGVQFp0lzmDaYSLyVTwGVCmoQn2TIh2anogkMxsO3FG0J6nKhFOU0xR0XuPlRTd UjxrjQHySUW60JUrq3tyUPc6Y1jpGNN6fT9NDa4Kis9a+nxOVmO014OD1/5TITUel9 E6VrrRQ8ogrl/MuRO5lSi6DFvWMvYkhfcw+mF+gJ3gd8HYvXhStgPB4JGyd9xgyHxJ 8Ik6vaOR8iCcsBBPh1bPN9c3lIXhcoZJ36iS9pAlTsv5iqxZRYoOvhknkrhtmGNrFr J6LRlgms0dH5bmgmuer21UPp+fu+68VOLC0KPHjEUZZGCYbXArw+Zh3B+6hO2fbz6C L6ZQPi8nngLLQ== Received: from [192.168.0.7] (unknown [IPv6:2804:14d:72b4:82f6:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id DCA8B17E1572; Wed, 30 Jul 2025 19:15:07 +0200 (CEST) From: Daniel Almeida Date: Wed, 30 Jul 2025 14:14:45 -0300 Subject: [PATCH 2/3] rust: lock: guard: add T: Unpin bound to DerefMut Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250730-lock-t-when-t-is-pinned-v1-2-1b97d5f28aa2@collabora.com> References: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com> In-Reply-To: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com> To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Miguel Ojeda , Alex Gaynor , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Daniel Almeida X-Mailer: b4 0.14.2 A core property of pinned types is not handing a mutable reference to the inner data in safe code, as this trivially allows that data to be moved. Enforce this condition by adding a bound on lock::Guard's DerefMut implementation, so that it's only implemented for pinning-agnostic types. Link: https://github.com/Rust-for-Linux/linux/issues/1181 Suggested-by: Benno Lossin Suggested-by: Boqun Feng Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl Reviewed-by: Benno Lossin --- rust/kernel/sync/lock.rs | 5 ++++- rust/kernel/sync/lock/global.rs | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs index 9715463cbab867a2cf59e75f03001d75e91bd7b6..087bc0391f92a73b9af18ca3146= 1b513bb5a9bcd 100644 --- a/rust/kernel/sync/lock.rs +++ b/rust/kernel/sync/lock.rs @@ -254,7 +254,10 @@ fn deref(&self) -> &Self::Target { } } =20 -impl core::ops::DerefMut for Guard<'_, T, B> { +impl core::ops::DerefMut for Guard<'_, T, B> +where + T: Unpin, +{ fn deref_mut(&mut self) -> &mut Self::Target { // SAFETY: The caller owns the lock, so it is safe to deref the pr= otected data. unsafe { &mut *self.lock.data.get() } diff --git a/rust/kernel/sync/lock/global.rs b/rust/kernel/sync/lock/global= .rs index d65f94b5caf2668586088417323496629492932f..38b44803279986275616eef499f= d40b8d4e97fdf 100644 --- a/rust/kernel/sync/lock/global.rs +++ b/rust/kernel/sync/lock/global.rs @@ -106,7 +106,10 @@ fn deref(&self) -> &Self::Target { } } =20 -impl core::ops::DerefMut for GlobalGuard { +impl core::ops::DerefMut for GlobalGuard +where + B::Item: Unpin, +{ fn deref_mut(&mut self) -> &mut Self::Target { &mut self.inner } --=20 2.50.1 From nobody Sun Oct 5 17:57:52 2025 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 2A9122E0B4E; Wed, 30 Jul 2025 17:15:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753895717; cv=none; b=qP3oXw0uDvB4/nF08DuFIm4cDCZeXW74CAmNJ+pZbTmn3FVs7Qzp+/l3YR9vpI3GMh+10Retjhis8gong/ho++DPxLdzscr7kd02IdFB2wg4RE5c1VsqoOMwT3NXWPH5e6hs/MooVna1VpjiV5lJ6zaBrrewE5RWZo5MIBZAXiQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753895717; c=relaxed/simple; bh=mTPBfKO4z4+W6J3cY3fLbZo21S5Y1PGCVi84PExWXcQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=U+GrNkcy3iYUsWRfsVQO3H5T4vaUPG0O5Tw4pZNxr9aYQqM5sUlDd+xAPozs3O4IZCWxKzGZP2FTOnm1CbYf5xuCl39qSJbEhewWAy4gUIR8uYTZFeQpxGAtK3LzIBdvXwGb8IjKYuUF8RY32R1n4mfJUrDWd9IOTK+VchAIKvU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=QRzF/Fbh; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="QRzF/Fbh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1753895713; bh=mTPBfKO4z4+W6J3cY3fLbZo21S5Y1PGCVi84PExWXcQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=QRzF/Fbh1UipAN19OrVb8tUoVGLk3DnLQXoCLm+6Mm4UTN4V0wAp0WDiI53s6Kgno B90DIqI/jC6i4/5tneT8kjdMonyrwv+Qxe88wfQIUJFLMppAScyOpYQf6Ueg3iK0Oq zcszsK65NkvXI78c0z+5aHYl+eozAp052mDsxLmW5Q4ndwFlxo06tce7pR481bR1jo uAYzfreFEsppBXMNAKU3FzOClgSfz7lz+0KfIXCd8DkV6s/xYIZJg2dtZChrfOS3AL gl2Z1REbU5oPYOKJ7q0RCpAC8JoomdPFVZlF2pu9pd4NCujjRziSHs0PBRbCA2Hejs Ez+3di4shtr0A== Received: from [192.168.0.7] (unknown [IPv6:2804:14d:72b4:82f6:67c:16ff:fe57:b5a3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dwlsalmeida) by bali.collaboradmins.com (Postfix) with ESMTPSA id CFC6717E15D4; Wed, 30 Jul 2025 19:15:10 +0200 (CEST) From: Daniel Almeida Date: Wed, 30 Jul 2025 14:14:46 -0300 Subject: [PATCH 3/3] rust: lock: add a Pin<&mut T> accessor Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250730-lock-t-when-t-is-pinned-v1-3-1b97d5f28aa2@collabora.com> References: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com> In-Reply-To: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com> To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Miguel Ojeda , Alex Gaynor , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Daniel Almeida X-Mailer: b4 0.14.2 In order for callers to be able to access the inner T safely if T: !Unpin, there needs to be a way to get a Pin<&mut T>. Add this accessor and a corresponding example to tell users how it works. This is not useful on its own for now, because we do not support pin projections yet. This means that the following is not going to compile: let mut data: MutexGuard<'_, Data> =3D mutex.lock(); let mut data: Pin<&mut Data> =3D data.as_mut(); let foo =3D &mut data.foo; A future patch can enable the behavior above by implementing support for pin projections. Link: https://github.com/Rust-for-Linux/linux/issues/1181 Suggested-by: Benno Lossin Suggested-by: Boqun Feng Signed-off-by: Daniel Almeida Reviewed-by: Alice Ryhl --- rust/kernel/sync/lock.rs | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs index 087bc0391f92a73b9af18ca31461b513bb5a9bcd..27857659a7f1ba4a8b844bb18d0= 09d037e0c5b03 100644 --- a/rust/kernel/sync/lock.rs +++ b/rust/kernel/sync/lock.rs @@ -243,6 +243,25 @@ pub(crate) fn do_unlocked(&mut self, cb: impl FnOnc= e() -> U) -> U { =20 cb() } + + /// Returns a pinned mutable reference to the protected data. + /// + /// # Examples + /// + /// ``` + /// # use kernel::sync::{Mutex, MutexGuard}; + /// # use core::pin::Pin; + /// struct Data; + /// + /// fn example(mutex: &Mutex) { + /// let mut data: MutexGuard<'_, Data> =3D mutex.lock(); + /// let mut data: Pin<&mut Data> =3D data.as_mut(); + /// } + /// ``` + pub fn as_mut(&mut self) -> Pin<&mut T> { + // SAFETY: `self.lock.data` is structurally pinned. + unsafe { Pin::new_unchecked(&mut *self.lock.data.get()) } + } } =20 impl core::ops::Deref for Guard<'_, T, B> { --=20 2.50.1