From: Beata Michalska <beata.michalska@arm.com>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: ojeda@kernel.org, alex.gaynor@gmail.com, dakr@kernel.org,
aliceryhl@google.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, lossin@kernel.org,
a.hindborg@kernel.org, tmgross@umich.edu, alyssa@rosenzweig.io,
lyude@redhat.com, rust-for-linux@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] rust: drm: Drop the use of Opaque for ioctl arguments
Date: Fri, 20 Jun 2025 14:17:08 +0200 [thread overview]
Message-ID: <aFVRRG9zTCXPn7zJ@arm.com> (raw)
In-Reply-To: <54E44DF8-1192-47B4-A9E3-5891D4BD7424@collabora.com>
On Thu, Jun 19, 2025 at 09:30:19AM -0300, Daniel Almeida wrote:
> Hi Beata,
>
> > On 19 Jun 2025, at 07:21, Beata Michalska <beata.michalska@arm.com> wrote:
> >
> > With the Opaque<T>, the expectations are that Rust should not make any
> > assumptions on the layout or invariants of the wrapped C types.
> > That runs rather counter to ioctl arguments, which must adhere to
> > certain data-layout constraints. By using Opaque<T>, ioctl handlers
> > end up doing unsound castings, which adds needless complexity and
> > maintenance overhead, brining no safety benefits.
>
> I don’t think that “unsound casts” is what is happening here.
>
> It's mostly the barrage of unsafe blocks to dereference the inner T for a
> problem that does not exist.
>
> > Drop the use of Opaque for ioctl arguments as that is not the best
> > fit here.
> >
> > Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> > ---
> >
> > Additional comments:
> > - UAPI types already automatically derive MaybeZeroable,
> > so it probably makes little sense to add any verification for that
> > - FromBytes is pending, but due to the orphan rule, adding verification
> > of it being implemented for IOCTL args here is pointless
>
> Even with this missing, I don’t see a problem with this patch.
The comments here are just informative and those are not a requirements
for this patch. Just a reference for things that might be needed.
>
> In fact, if anything, the result of the discussion so far seems to point
> towards automatically implementing FromBytes for all uapi types.
That's what the 'pending' was supposed to mean. Will me more specific next
time.
---
BR
Beata
>
>
> > - Verifying pointer alignment could make use of strict_provenance,
> > but that one is unstable and I am not sure what are the exact rules
> > here for using those. Without that one though, verifying alignment in
> > some cases (i.e. pointer tagging) might require more extensive changes.
> > Happy to deal with either.
> >
> > rust/kernel/drm/ioctl.rs | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/rust/kernel/drm/ioctl.rs b/rust/kernel/drm/ioctl.rs
> > index 445639404fb7..12b296131672 100644
> > --- a/rust/kernel/drm/ioctl.rs
> > +++ b/rust/kernel/drm/ioctl.rs
> > @@ -139,7 +139,7 @@ pub mod internal {
> > // asserted above matches the size of this type, and all bit patterns of
> > // UAPI structs must be valid.
> > let data = unsafe {
> > - &*(raw_data as *const $crate::types::Opaque<$crate::uapi::$struct>)
> > + &mut *(raw_data as *mut $crate::uapi::$struct)
> > };
> > // SAFETY: This is just the DRM file structure
> > let file = unsafe { $crate::drm::File::as_ref(raw_file) };
> > --
> > 2.25.1
> >
> >
>
> — Daniel
>
prev parent reply other threads:[~2025-06-20 12:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 10:21 [PATCH] rust: drm: Drop the use of Opaque for ioctl arguments Beata Michalska
2025-06-19 10:55 ` Danilo Krummrich
2025-06-19 11:01 ` Benno Lossin
2025-06-19 12:26 ` Daniel Almeida
2025-06-19 12:31 ` Daniel Almeida
2025-06-19 13:17 ` Benno Lossin
2025-06-19 18:51 ` Boqun Feng
2025-06-20 12:25 ` Beata Michalska
2025-06-20 13:42 ` Daniel Almeida
2025-06-23 8:14 ` Beata Michalska
2025-06-19 12:34 ` Alice Ryhl
2025-06-19 13:01 ` Danilo Krummrich
2025-06-20 12:17 ` Beata Michalska
2025-06-19 12:30 ` Daniel Almeida
2025-06-20 12:17 ` Beata Michalska [this message]
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=aFVRRG9zTCXPn7zJ@arm.com \
--to=beata.michalska@arm.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=alyssa@rosenzweig.io \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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.