From nobody Sat Feb 7 05:57:37 2026 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 ADC672F44; Sat, 26 Apr 2025 13:33:36 +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=1745674416; cv=none; b=Ty7zPbaQ6u/HiuM2RraqwzY/VpM5o0pgx0Q3O/SyDl8X15F2xCLMqNj8+RYybFU/r6PMCIZorKwVDY8cWrxR+bpkD4QVzlMwXqvzSHLY1yL8G6qMXIRB8QLP8sKj6Niflm+AZcrmmFTJm/gG5000DMAGGvJcGx53pCPWJZaymG8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745674416; c=relaxed/simple; bh=xSy/gE7sRWmsVIrx2/LKqUD05Ok0iMNH2/orbll76Sw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eSiWZaa4LJWxrN9ahMioTsQ3T11o+heclzWOKBBeEplqPpaqioj2sqZ41lwK7vbsDRYepVZX33Yj+o1t4uSEnoQVJHe/HLVQnhRpFKYNiTS7K1PlKxYC+HJLGixU0dJXJMNr0APxitvQaPvTQVqlkzXK0Bs/Lkd17gcfXkxyf8M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DDRbVIQW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DDRbVIQW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2747C4CEE2; Sat, 26 Apr 2025 13:33:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745674416; bh=xSy/gE7sRWmsVIrx2/LKqUD05Ok0iMNH2/orbll76Sw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DDRbVIQWjMqQY9K5X1ptTXvtqX+LGm+wf9gsFSbZcFFFtEgotECWMEltSoQ4lTBeE o8ovYHMonR/US9Zvrwjg73lX+qrCzedkWiBm8mBJC3m0yTgMPsjkKsD0cuHSdmus9V 7pVb3VU+PCKzpdwjXmvdOPzyUiTh+nmV85WJAcAtpXLzIq5k/CGjGUoqcIPhc9n3Iq iYmE9sl+80ffHpp1x/nbbfgv3tYIdMorenmQMIM0YfbEKA0x5OiL4C70YGxLuEZ1Dk HAp0YaY22pessLyZ4QRJa+a4GcNfsKa956o/8vp1rjkL6YN2k2MGT387ab4xRnQjNN 1Q8LCkgDeFTrQ== From: Danilo Krummrich To: gregkh@linuxfoundation.org, rafael@kernel.org, bhelgaas@google.com, kwilczynski@kernel.org, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, bskeggs@nvidia.com, acurrid@nvidia.com, joelagnelf@nvidia.com, ttabi@nvidia.com, acourbot@nvidia.com, ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu Cc: linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Danilo Krummrich Subject: [PATCH 1/3] rust: revocable: implement Revocable::access() Date: Sat, 26 Apr 2025 15:30:39 +0200 Message-ID: <20250426133254.61383-2-dakr@kernel.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250426133254.61383-1-dakr@kernel.org> References: <20250426133254.61383-1-dakr@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Implement an unsafe direct accessor for the data stored within the Revocable. This is useful for cases where we can proof that the data stored within the Revocable is not and cannot be revoked for the duration of the lifetime of the returned reference. Signed-off-by: Danilo Krummrich Reviewed-by: Christian Schrefl --- The explicit lifetimes in access() probably don't serve a practical purpose, but I found them to be useful for documentation purposes. --- rust/kernel/revocable.rs | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/rust/kernel/revocable.rs b/rust/kernel/revocable.rs index 971d0dc38d83..33535de141ce 100644 --- a/rust/kernel/revocable.rs +++ b/rust/kernel/revocable.rs @@ -139,6 +139,18 @@ pub fn try_access_with R>(&self, f= : F) -> Option { self.try_access().map(|t| f(&*t)) } =20 + /// Directly access the revocable wrapped object. + /// + /// # Safety + /// + /// The caller must ensure this [`Revocable`] instance hasn't been rev= oked and won't be revoked + /// for the duration of `'a`. + pub unsafe fn access<'a, 's: 'a>(&'s self) -> &'a T { + // SAFETY: By the safety requirement of this function it is guaran= teed that + // `self.data.get()` is a valid pointer to an instance of `T`. + unsafe { &*self.data.get() } + } + /// # Safety /// /// Callers must ensure that there are no more concurrent users of the= revocable object. --=20 2.49.0 From nobody Sat Feb 7 05:57:37 2026 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 EFAE21B81C1; Sat, 26 Apr 2025 13:33:41 +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=1745674422; cv=none; b=dzaJ2dTd4WBdGbgsfloOYn485YZnRX5P6418dgnDjVmc0Wpl5zcLhKyzBzCeRVMpIDZjcYISyRZizz0yMxGyX7X18TbX2DTSLpaIAiLUNmJD1JQNABhy2/ADOKv9SEgdTJE+tkxoYgZcZGuLRdr2zSSl5qUTn5uW1wOLoz5X3Mw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745674422; c=relaxed/simple; bh=UW+j65AYZdybdRL+KuUdB/sVtlErJkIEvsNeks47yGo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F9b1bs8qJDkh7tprfmdi5azz0D2v354ek+53ttHVkdGW1etCqVASsTalV3imdZ3PmCLy4JG0EQWKEsIm8swaur9LpLMcYACT0SjQ3mFKh88odrxPxDI0FHyMEsKrEVxH6/i1K/rEQy7JC+3NuQpXRK+X33C7czH/IJuTA7OVfM0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zag3MiWr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Zag3MiWr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A222C4CEE2; Sat, 26 Apr 2025 13:33:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745674421; bh=UW+j65AYZdybdRL+KuUdB/sVtlErJkIEvsNeks47yGo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zag3MiWr0NmzUNNuwkhGufY7DfjrUl2ClThRXYGi/qLuun/Kez9hJBY7urs1YFQ59 FhzGoIMYOt/C+M1pZoaH3Dlh3/HDn3X5XKabhKQFk5Ee8QLMAfSE0NakNXumqCnstD Yc5yLZw+ReduCmIWC0VLqf8UEgLdE8NFuyE/p7C6uvmDE2tGjFpysJ6BIsRlpXad/J ODp3Z+2q3C/38fHshVZZaZQNbG1DxlxzuACk1EZenxM/69nc5Fw3F8cdI5CEMpMhJT a9B4YRCq9JxurXkP1bB2PbUe0/P7hyTMmR5ScNXbakzDYCDsZdXC/zP2wAfmgHYw1A MupvNrqWdM4Dw== From: Danilo Krummrich To: gregkh@linuxfoundation.org, rafael@kernel.org, bhelgaas@google.com, kwilczynski@kernel.org, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, bskeggs@nvidia.com, acurrid@nvidia.com, joelagnelf@nvidia.com, ttabi@nvidia.com, acourbot@nvidia.com, ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu Cc: linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Danilo Krummrich Subject: [PATCH 2/3] rust: devres: implement Devres::access_with() Date: Sat, 26 Apr 2025 15:30:40 +0200 Message-ID: <20250426133254.61383-3-dakr@kernel.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250426133254.61383-1-dakr@kernel.org> References: <20250426133254.61383-1-dakr@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Implement a direct accessor for the data stored within the Devres for cases where we can proof that we own a reference to a Device (i.e. a bound device) of the same device that was used to create the corresponding Devres container. Usually, when accessing the data stored within a Devres container, it is not clear whether the data has been revoked already due to the device being unbound and, hence, we have to try whether the access is possible and subsequently keep holding the RCU read lock for the duration of the access. However, when we can proof that we hold a reference to Device matching the device the Devres container has been created with, we can guarantee that the device is not unbound for the duration of the lifetime of the Device reference and, hence, it is not possible for the data within the Devres container to be revoked. Therefore, in this case, we can bypass the atomic check and the RCU read lock, which is a great optimization and simplification for drivers. Signed-off-by: Danilo Krummrich Reviewed-by: Christian Schrefl --- rust/kernel/devres.rs | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/rust/kernel/devres.rs b/rust/kernel/devres.rs index 1e58f5d22044..ec2cd9cdda8b 100644 --- a/rust/kernel/devres.rs +++ b/rust/kernel/devres.rs @@ -181,6 +181,41 @@ pub fn new_foreign_owned(dev: &Device, data: T,= flags: Flags) -> Result { =20 Ok(()) } + + /// Obtain `&'a T`, bypassing the [`Revocable`]. + /// + /// This method allows to directly obtain a `&'a T`, bypassing the [`R= evocable`], by presenting + /// a `&'a Device` of the same [`Device`] this [`Devres`] insta= nce has been created with. + /// + /// An error is returned if `dev` does not match the same [`Device`] t= his [`Devres`] instance + /// has been created with. + /// + /// # Example + /// + /// ```no_run + /// # use kernel::{device::Core, devres::Devres, pci}; + /// + /// fn from_core(dev: &pci::Device, devres: Devres= >) -> Result<()> { + /// let bar =3D devres.access_with(dev.as_ref())?; + /// + /// let _ =3D bar.read32(0x0); + /// + /// // might_sleep() + /// + /// bar.write32(0x42, 0x0); + /// + /// Ok(()) + /// } + pub fn access_with<'s, 'd: 's>(&'s self, dev: &'d Device) -> Re= sult<&'s T> { + if self.0.dev.as_raw() !=3D dev.as_raw() { + return Err(EINVAL); + } + + // SAFETY: `dev` being the same device as the device this `Devres`= has been created for + // proofes that `self.0.data` hasn't been revoked and is guarantee= d to not be revoked as + // long as `dev` lives; `dev` lives at least as long as `self`. + Ok(unsafe { self.deref().access() }) + } } =20 impl Deref for Devres { --=20 2.49.0 From nobody Sat Feb 7 05:57:37 2026 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 348D319AA63; Sat, 26 Apr 2025 13:33:47 +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=1745674427; cv=none; b=Yi2HQ+X6Me4Be2Jv5PWQ2QESTE+8Q2CCyOvmFmED1FWBFR1p4gaYH0019odx6b5mha2rp+9rwdIXwm3J6lmeNvfytWF1lihgJ+pLki2AkFbRzSTFlQtbmQppu8kdRSgKbjE7/V0C3iMrvHLKcSwy2ZP0eM/0CsC6gcTCdrCoQQY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745674427; c=relaxed/simple; bh=laYEX4TBOsk4CcxMpavBgNe9zSjYXY1+gGE9Nqbpo0o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PDSrjxsV0H/VHnxwcLw3sjm1ePvQ/T7b2+lLvAl7mVA/0OQrnIwfTES+8rOMhDBa8Cgg4zUkkf7i9Eo6aUhdFIhHYlkHRknfI+wTk4bcHL+EOTmDw+3oe8sA3+vwv9RL+qzSlzFW5CP7ZCqS0+Hv+UTYpJ3kCua2/9CGAs2ZDPs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YFAQNP3o; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YFAQNP3o" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 461BEC4CEEB; Sat, 26 Apr 2025 13:33:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745674427; bh=laYEX4TBOsk4CcxMpavBgNe9zSjYXY1+gGE9Nqbpo0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YFAQNP3o2dgumNhdt4IINojtRaRI0vPHnjCeANYqFDQAOA9JqJ+uosVRwgYL1fDSt /qxgQo7YqICaJR1znVoKBL94DooX65wr9AmMbcOaxdQYyApo0smumJG/S0RDu0/RNV OHTIm57p1XzQN2+rrmtc39VQHzjV6RJpYeKR077q8Wo649xQ0+NqRtMaVLEKl/dxOL luuD2UPXVLt0WUwCArTj+SkRux7pc/neUb2GgReXgaTeJNkec3v4uSWv3fjj/y27kQ 5SLAKmV9WrxznBBd7KZA2rlcSry+OzG2bl6aTzN4nlhpvO9Xc9cWoMBI7TxUvXo2Hj WjfU683UKqmqg== From: Danilo Krummrich To: gregkh@linuxfoundation.org, rafael@kernel.org, bhelgaas@google.com, kwilczynski@kernel.org, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, bskeggs@nvidia.com, acurrid@nvidia.com, joelagnelf@nvidia.com, ttabi@nvidia.com, acourbot@nvidia.com, ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu Cc: linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Danilo Krummrich Subject: [PATCH 3/3] samples: rust: pci: take advantage of Devres::access_with() Date: Sat, 26 Apr 2025 15:30:41 +0200 Message-ID: <20250426133254.61383-4-dakr@kernel.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250426133254.61383-1-dakr@kernel.org> References: <20250426133254.61383-1-dakr@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For the I/O operations executed from the probe() method, take advantage of Devres::access_with(), avoiding the atomic check and RCU read lock required otherwise entirely. Signed-off-by: Danilo Krummrich --- samples/rust/rust_driver_pci.rs | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/samples/rust/rust_driver_pci.rs b/samples/rust/rust_driver_pci= .rs index 9ce3a7323a16..3e1569e5096e 100644 --- a/samples/rust/rust_driver_pci.rs +++ b/samples/rust/rust_driver_pci.rs @@ -83,12 +83,12 @@ fn probe(pdev: &pci::Device, info: &Self::IdInfo)= -> Result GFP_KERNEL, )?; =20 - let res =3D drvdata - .bar - .try_access_with(|b| Self::testdev(info, b)) - .ok_or(ENXIO)??; - - dev_info!(pdev.as_ref(), "pci-testdev data-match count: {}\n", res= ); + let bar =3D drvdata.bar.access_with(pdev.as_ref())?; + dev_info!( + pdev.as_ref(), + "pci-testdev data-match count: {}\n", + Self::testdev(info, bar)? + ); =20 Ok(drvdata.into()) } --=20 2.49.0