From: "Danilo Krummrich" <dakr@kernel.org>
To: "Lyude Paul" <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
Miguel Ojeda <ojeda@kernel.org>, Simona Vetter <simona@ffwll.ch>,
Alice Ryhl <aliceryhl@google.com>,
Shankari Anand <shankari.ak0208@gmail.com>,
Benno Lossin <lossin@kernel.org>,
Asahi Lina <lina+kernel@asahilina.net>,
Atharv Dubey <atharvd440@gmail.com>,
Daniel Almeida <daniel.almeida@collabora.com>
Subject: Re: [PATCH v2 2/3] rust/drm: Don't setup private driver data until registration
Date: Sun, 18 Jan 2026 15:36:13 +0100 [thread overview]
Message-ID: <DFRSH2462TT2.RZBLN08KS0IW@kernel.org> (raw)
In-Reply-To: <20260116204728.725579-3-lyude@redhat.com>
On Fri Jan 16, 2026 at 9:41 PM CET, Lyude Paul wrote:
> @@ -118,7 +120,7 @@ pub trait DeviceContext: Sealed + Send + Sync {}
> ///
> /// The device in `self.0` is guaranteed to be a newly created [`Device`] that has not yet been
> /// registered with userspace until this type is dropped.
> -pub struct UnregisteredDevice<T: drm::Driver>(ARef<Device<T, Uninit>>, NotThreadSafe);
> +pub struct UnregisteredDevice<T: drm::Driver>(pub(crate) ARef<Device<T, Uninit>>, NotThreadSafe);
>
> impl<T: drm::Driver> Deref for UnregisteredDevice<T> {
> type Target = Device<T, Uninit>;
> @@ -165,7 +167,7 @@ impl<T: drm::Driver> UnregisteredDevice<T> {
> /// Create a new `UnregisteredDevice` for a `drm::Driver`.
> ///
> /// This can be used to create a [`Registration`](kernel::drm::Registration).
> - pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<Self> {
> + pub fn new(dev: &device::Device) -> Result<Self> {
> // `__drm_dev_alloc` uses `kmalloc()` to allocate memory, hence ensure a `kmalloc()`
> // compatible `Layout`.
> let layout = Kmalloc::aligned_layout(Layout::new::<Self>());
> @@ -184,22 +186,6 @@ pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<S
> .cast();
> let raw_drm = NonNull::new(from_err_ptr(raw_drm)?).ok_or(ENOMEM)?;
>
> - // SAFETY: `raw_drm` is a valid pointer to `Self`.
> - let raw_data = unsafe { ptr::addr_of_mut!((*raw_drm.as_ptr()).data) };
> -
> - // SAFETY:
> - // - `raw_data` is a valid pointer to uninitialized memory.
> - // - `raw_data` will not move until it is dropped.
> - unsafe { data.__pinned_init(raw_data) }.inspect_err(|_| {
> - // SAFETY: `raw_drm` is a valid pointer to `Self`, given that `__drm_dev_alloc` was
> - // successful.
> - let drm_dev = unsafe { Device::into_drm_device(raw_drm) };
> -
> - // SAFETY: `__drm_dev_alloc()` was successful, hence `drm_dev` must be valid and the
> - // refcount must be non-zero.
> - unsafe { bindings::drm_dev_put(drm_dev) };
> - })?;
> -
> // SAFETY: The reference count is one, and now we take ownership of that reference as a
> // `drm::Device`.
> // INVARIANT: We just created the device above, but have yet to call `drm_dev_register`.
> @@ -231,7 +217,15 @@ pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<S
> #[repr(C)]
> pub struct Device<T: drm::Driver, C: DeviceContext = Registered> {
> dev: Opaque<bindings::drm_device>,
> - data: T::Data,
> +
> + /// Keeps track of whether we've initialized the device data yet.
> + pub(crate) data_is_init: AtomicBool,
Please use a kernel atomic, i.e. kernel::sync::atomic::Atomic<bool>. See also [1].
[1] https://lore.kernel.org/all/20251230093718.1852322-1-fujita.tomonori@gmail.com/
> + /// The Driver's private data.
> + ///
> + /// This must only be written to from [`drm::Registration::new`].
> + pub(crate) data: UnsafeCell<MaybeUninit<T::Data>>,
Why not just Opaque<T::Data>?
> +
> _ctx: PhantomData<C>,
> }
WARNING: multiple messages have this Message-ID (diff)
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Lyude Paul" <lyude@redhat.com>
Cc: <dri-devel@lists.freedesktop.org>,
<nouveau@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Simona Vetter" <simona@ffwll.ch>,
"Alice Ryhl" <aliceryhl@google.com>,
"Shankari Anand" <shankari.ak0208@gmail.com>,
"David Airlie" <airlied@gmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Asahi Lina" <lina+kernel@asahilina.net>,
"Atharv Dubey" <atharvd440@gmail.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>
Subject: Re: [PATCH v2 2/3] rust/drm: Don't setup private driver data until registration
Date: Sun, 18 Jan 2026 15:36:13 +0100 [thread overview]
Message-ID: <DFRSH2462TT2.RZBLN08KS0IW@kernel.org> (raw)
In-Reply-To: <20260116204728.725579-3-lyude@redhat.com>
On Fri Jan 16, 2026 at 9:41 PM CET, Lyude Paul wrote:
> @@ -118,7 +120,7 @@ pub trait DeviceContext: Sealed + Send + Sync {}
> ///
> /// The device in `self.0` is guaranteed to be a newly created [`Device`] that has not yet been
> /// registered with userspace until this type is dropped.
> -pub struct UnregisteredDevice<T: drm::Driver>(ARef<Device<T, Uninit>>, NotThreadSafe);
> +pub struct UnregisteredDevice<T: drm::Driver>(pub(crate) ARef<Device<T, Uninit>>, NotThreadSafe);
>
> impl<T: drm::Driver> Deref for UnregisteredDevice<T> {
> type Target = Device<T, Uninit>;
> @@ -165,7 +167,7 @@ impl<T: drm::Driver> UnregisteredDevice<T> {
> /// Create a new `UnregisteredDevice` for a `drm::Driver`.
> ///
> /// This can be used to create a [`Registration`](kernel::drm::Registration).
> - pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<Self> {
> + pub fn new(dev: &device::Device) -> Result<Self> {
> // `__drm_dev_alloc` uses `kmalloc()` to allocate memory, hence ensure a `kmalloc()`
> // compatible `Layout`.
> let layout = Kmalloc::aligned_layout(Layout::new::<Self>());
> @@ -184,22 +186,6 @@ pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<S
> .cast();
> let raw_drm = NonNull::new(from_err_ptr(raw_drm)?).ok_or(ENOMEM)?;
>
> - // SAFETY: `raw_drm` is a valid pointer to `Self`.
> - let raw_data = unsafe { ptr::addr_of_mut!((*raw_drm.as_ptr()).data) };
> -
> - // SAFETY:
> - // - `raw_data` is a valid pointer to uninitialized memory.
> - // - `raw_data` will not move until it is dropped.
> - unsafe { data.__pinned_init(raw_data) }.inspect_err(|_| {
> - // SAFETY: `raw_drm` is a valid pointer to `Self`, given that `__drm_dev_alloc` was
> - // successful.
> - let drm_dev = unsafe { Device::into_drm_device(raw_drm) };
> -
> - // SAFETY: `__drm_dev_alloc()` was successful, hence `drm_dev` must be valid and the
> - // refcount must be non-zero.
> - unsafe { bindings::drm_dev_put(drm_dev) };
> - })?;
> -
> // SAFETY: The reference count is one, and now we take ownership of that reference as a
> // `drm::Device`.
> // INVARIANT: We just created the device above, but have yet to call `drm_dev_register`.
> @@ -231,7 +217,15 @@ pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<S
> #[repr(C)]
> pub struct Device<T: drm::Driver, C: DeviceContext = Registered> {
> dev: Opaque<bindings::drm_device>,
> - data: T::Data,
> +
> + /// Keeps track of whether we've initialized the device data yet.
> + pub(crate) data_is_init: AtomicBool,
Please use a kernel atomic, i.e. kernel::sync::atomic::Atomic<bool>. See also [1].
[1] https://lore.kernel.org/all/20251230093718.1852322-1-fujita.tomonori@gmail.com/
> + /// The Driver's private data.
> + ///
> + /// This must only be written to from [`drm::Registration::new`].
> + pub(crate) data: UnsafeCell<MaybeUninit<T::Data>>,
Why not just Opaque<T::Data>?
> +
> _ctx: PhantomData<C>,
> }
next prev parent reply other threads:[~2026-01-18 14:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 20:41 [PATCH v2 0/3] Introduce DeviceContext Lyude Paul
2026-01-16 20:41 ` Lyude Paul
2026-01-16 20:41 ` [PATCH v2 1/3] rust/drm: " Lyude Paul
2026-01-16 20:41 ` Lyude Paul
2026-01-18 14:27 ` Danilo Krummrich
2026-01-18 14:27 ` Danilo Krummrich
2026-01-16 20:41 ` [PATCH v2 2/3] rust/drm: Don't setup private driver data until registration Lyude Paul
2026-01-16 20:41 ` Lyude Paul
2026-01-18 14:36 ` Danilo Krummrich [this message]
2026-01-18 14:36 ` Danilo Krummrich
2026-01-16 20:41 ` [PATCH v2 3/3] rust/drm/gem: Use DeviceContext with GEM objects Lyude Paul
2026-01-16 20:41 ` Lyude Paul
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=DFRSH2462TT2.RZBLN08KS0IW@kernel.org \
--to=dakr@kernel.org \
--cc=aliceryhl@google.com \
--cc=atharvd440@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=lina+kernel@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shankari.ak0208@gmail.com \
--cc=simona@ffwll.ch \
/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.