From: Danilo Krummrich <dakr@kernel.org>
To: Tamir Duberstein <tamird@gmail.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Matthew Wilcox" <willy@infradead.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Maíra Canal" <mcanal@igalia.com>,
"Asahi Lina" <lina@asahilina.net>,
rust-for-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v15 1/3] rust: types: add `ForeignOwnable::PointedTo`
Date: Thu, 6 Feb 2025 17:39:14 +0100 [thread overview]
Message-ID: <Z6Tlsn2RIiE121Lg@cassiopeiae> (raw)
In-Reply-To: <20250206-rust-xarray-bindings-v15-1-a22b5dcacab3@gmail.com>
On Thu, Feb 06, 2025 at 11:24:43AM -0500, Tamir Duberstein wrote:
> Allow implementors to specify the foreign pointer type; this exposes
> information about the pointed-to type such as its alignment.
>
> This requires the trait to be `unsafe` since it is now possible for
> implementors to break soundness by returning a misaligned pointer.
>
> Encoding the pointer type in the trait (and avoiding pointer casts)
> allows the compiler to check that implementors return the correct
> pointer type. This is preferable to directly encoding the alignment in
> the trait using a constant as the compiler would be unable to check it.
>
> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Tamir Duberstein <tamird@gmail.com>
> ---
> rust/kernel/alloc/kbox.rs | 38 ++++++++++++++++++++------------------
> rust/kernel/miscdevice.rs | 7 ++++++-
> rust/kernel/pci.rs | 5 ++++-
> rust/kernel/platform.rs | 5 ++++-
> rust/kernel/sync/arc.rs | 21 ++++++++++++---------
> rust/kernel/types.rs | 46 +++++++++++++++++++++++++++++++---------------
> 6 files changed, 77 insertions(+), 45 deletions(-)
>
> diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> index e14433b2ab9d..f1a081dd64c7 100644
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@ -225,13 +225,15 @@ impl<T: MiscDevice> VtableHelper<T> {
> Ok(ptr) => ptr,
> Err(err) => return err.to_errno(),
> };
> + let ptr = ptr.into_foreign();
> + let ptr = ptr.cast();
>
> // This overwrites the private data with the value specified by the user, changing the type of
> // this file's private data. All future accesses to the private data is performed by other
> // fops_* methods in this file, which all correctly cast the private data to the new type.
> //
> // SAFETY: The open call of a file can access the private data.
> - unsafe { (*raw_file).private_data = ptr.into_foreign() };
> + unsafe { (*raw_file).private_data = ptr };
Why not just ptr.into_foreign().cast()?
>
> 0
> }
> @@ -246,6 +248,7 @@ impl<T: MiscDevice> VtableHelper<T> {
> ) -> c_int {
> // SAFETY: The release call of a file owns the private data.
> let private = unsafe { (*file).private_data };
> + let private = private.cast();
> // SAFETY: The release call of a file owns the private data.
> let ptr = unsafe { <T::Ptr as ForeignOwnable>::from_foreign(private) };
>
> @@ -267,6 +270,7 @@ impl<T: MiscDevice> VtableHelper<T> {
> ) -> c_long {
> // SAFETY: The ioctl call of a file can access the private data.
> let private = unsafe { (*file).private_data };
> + let private = private.cast();
> // SAFETY: Ioctl calls can borrow the private data of the file.
> let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>
> @@ -316,6 +320,7 @@ impl<T: MiscDevice> VtableHelper<T> {
> ) {
> // SAFETY: The release call of a file owns the private data.
> let private = unsafe { (*file).private_data };
> + let private = private.cast();
> // SAFETY: Ioctl calls can borrow the private data of the file.
> let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
> // SAFETY:
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index 4c98b5b9aa1e..eb25fabbff9c 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
> @@ -72,10 +72,12 @@ extern "C" fn probe_callback(
>
> match T::probe(&mut pdev, info) {
> Ok(data) => {
> + let data = data.into_foreign();
> + let data = data.cast();
> // Let the `struct pci_dev` own a reference of the driver's private data.
> // SAFETY: By the type invariant `pdev.as_raw` returns a valid pointer to a
> // `struct pci_dev`.
> - unsafe { bindings::pci_set_drvdata(pdev.as_raw(), data.into_foreign() as _) };
> + unsafe { bindings::pci_set_drvdata(pdev.as_raw(), data) };
This change isn't necessary for this patch, is it? I think it makes sense to
replace `as _` with cast(), but this should be a separate patch then.
> }
> Err(err) => return Error::to_errno(err),
> }
> @@ -87,6 +89,7 @@ extern "C" fn remove_callback(pdev: *mut bindings::pci_dev) {
> // SAFETY: The PCI bus only ever calls the remove callback with a valid pointer to a
> // `struct pci_dev`.
> let ptr = unsafe { bindings::pci_get_drvdata(pdev) };
> + let ptr = ptr.cast();
>
> // SAFETY: `remove_callback` is only ever called after a successful call to
> // `probe_callback`, hence it's guaranteed that `ptr` points to a valid and initialized
> diff --git a/rust/kernel/platform.rs b/rust/kernel/platform.rs
> index 50e6b0421813..53764cb7f804 100644
> --- a/rust/kernel/platform.rs
> +++ b/rust/kernel/platform.rs
> @@ -63,10 +63,12 @@ extern "C" fn probe_callback(pdev: *mut bindings::platform_device) -> kernel::ff
> let info = <Self as driver::Adapter>::id_info(pdev.as_ref());
> match T::probe(&mut pdev, info) {
> Ok(data) => {
> + let data = data.into_foreign();
> + let data = data.cast();
> // Let the `struct platform_device` own a reference of the driver's private data.
> // SAFETY: By the type invariant `pdev.as_raw` returns a valid pointer to a
> // `struct platform_device`.
> - unsafe { bindings::platform_set_drvdata(pdev.as_raw(), data.into_foreign() as _) };
> + unsafe { bindings::platform_set_drvdata(pdev.as_raw(), data) };
Same here.
next prev parent reply other threads:[~2025-02-06 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 16:24 [PATCH v15 0/3] rust: xarray: Add a minimal abstraction for XArray Tamir Duberstein
2025-02-06 16:24 ` [PATCH v15 1/3] rust: types: add `ForeignOwnable::PointedTo` Tamir Duberstein
2025-02-06 16:39 ` Danilo Krummrich [this message]
2025-02-06 17:22 ` Tamir Duberstein
2025-02-06 18:36 ` Andreas Hindborg
2025-02-06 16:24 ` [PATCH v15 2/3] rust: xarray: Add an abstraction for XArray Tamir Duberstein
2025-02-06 17:18 ` Boqun Feng
2025-02-06 18:21 ` Tamir Duberstein
2025-02-06 20:57 ` Boqun Feng
2025-02-06 21:35 ` Tamir Duberstein
2025-02-06 16:24 ` [PATCH v15 3/3] MAINTAINERS: add entry for Rust XArray API Tamir Duberstein
2025-02-06 18:40 ` Andreas Hindborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z6Tlsn2RIiE121Lg@cassiopeiae \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lina@asahilina.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mcanal@igalia.com \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@gmail.com \
--cc=tmgross@umich.edu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.