From nobody Fri Dec 19 17:36:02 2025 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 AC2B826B2D6; Mon, 28 Apr 2025 14:01:56 +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=1745848917; cv=none; b=Svaj77cY0GO+eerR+8T9pbo59mKaxCmU9vRWCyQvkj422cxNY02U9ZqT+c/vvG5hjedXTsx9Z6NfvS52Se16ZRbUo28guLdpWKv/LtDGxIzXWNEsJX4tGnCZ2VPhfzjIhPsXf9c3Jk4xET5VcBbTDfpbXAS3bI/Rlu/J8LLKE7Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745848917; c=relaxed/simple; bh=5M8AWy35CAncMHrQE1PZU5bOW2RDloVLDLoTAFvZ3MA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aO6HIAtZxR08d+u6626yNKEoFWY6RMiZHI2eVhpbi2x5yGah//LytTqk2NYV7QLoOCGHi9cy7mBHGZ9TeuKYIkz6dfA0gbAyfT874D1YdKRV07H+dNzCsP/zEU12xOs+8SN94GS6CJyG1g7mB2CwRAsI0B9M1CGmWN2+fK7suXk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=id8IA0JP; 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="id8IA0JP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29D5DC4CEE4; Mon, 28 Apr 2025 14:01:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745848916; bh=5M8AWy35CAncMHrQE1PZU5bOW2RDloVLDLoTAFvZ3MA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=id8IA0JP+++5cZz4RIVLAbb1dShoh3Nm0GaSCXncUuOVlz81ErC1HXtWd+Suk1g9m HUE3DDZ1Vw8xb/XR3aNaFc9YISQ14Jg7fliGaSF2AGIkM1fQYzi21XkNOxH7e2/p1O z/0HHzMrsepWG7+j3Vwt0+zcN92e7CLHkCzPeEHmRmZPA4AibqWiD5gEe1i3SISbc1 7hPcfWcbq7NuLDiflZLAe5JE0lKZ05i0f+rNN67oHR7p8CsS8EuRIzO+NrmWkB7QB8 HJRwbQej3AV021hXQfjzU0Ih41DqT4Ms6A5oYHOj+Fo4k2Dcrtr45sYs68h1gognBc gMuSy/53r/HgQ== 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 , Christian Schrefl Subject: [PATCH v2 2/3] rust: devres: implement Devres::access_with() Date: Mon, 28 Apr 2025 16:00:28 +0200 Message-ID: <20250428140137.468709-3-dakr@kernel.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250428140137.468709-1-dakr@kernel.org> References: <20250428140137.468709-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 prove 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 prove 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. Reviewed-by: Christian Schrefl Signed-off-by: Danilo Krummrich --- rust/kernel/devres.rs | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/rust/kernel/devres.rs b/rust/kernel/devres.rs index 1e58f5d22044..cf6fc09b2c05 100644 --- a/rust/kernel/devres.rs +++ b/rust/kernel/devres.rs @@ -181,6 +181,44 @@ 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. + /// + /// # Errors + /// + /// 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(dev.as_ref())?; + /// + /// let _ =3D bar.read32(0x0); + /// + /// // might_sleep() + /// + /// bar.write32(0x42, 0x0); + /// + /// Ok(()) + /// } + /// ``` + pub fn access<'a>(&'a self, dev: &'a Device) -> Result<&'a 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 + // proves that `self.0.data` hasn't been revoked and is guaranteed= 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