From: sashiko-bot@kernel.org
To: "Danilo Krummrich" <dakr@kernel.org>,
aliceryhl@google.com, acourbot@nvidia.com,
daniel.almeida@collabora.com, ojeda@kernel.org, boqun@kernel.org,
gary@garyguo.net, bjorn3_gh@protonmail.com, lossin@kernel.org,
a.hindborg@kernel.org, tmgross@umich.edu, tamird@kernel.org,
work@onurozkan.dev, brauner@kernel.org, lyude@redhat.com,
j@jananu.net, alvin.sun@linux.dev, deborah.brouwer@collabora.com,
laura.nao@collabora.com, beata.michalska@arm.com
Cc: nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 7/7] rust: drm: make Driver::File lifetime-parameterized
Date: Sat, 07 Nov 2026 02:34:49 +0000 [thread overview]
Message-ID: <sashiko-outbox-202513@kernel.org> (raw)
In-Reply-To: <20261107021427.2105374-8-dakr@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] rust: drm: missing Send + Sync bounds on Driver::File and
DriverFile
--
commit 229740f5d6f5f9093208d976d2ea98edc170b6f8
Author: Danilo Krummrich <dakr@kernel.org>
rust: drm: make Driver::File lifetime-parameterized
This commit lifetime-parameterizes Driver::File and DriverFile so per-file
driver data can borrow from RegistrationData, and drops open file data
before registration teardown completes.
> diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs
> index f6db91e81e794..92055c4f9e00c 100644
> --- a/rust/kernel/drm/driver.rs
> +++ b/rust/kernel/drm/driver.rs
[ ... ]
> @@ -120,8 +132,14 @@ pub trait Driver {
> /// The type used to manage memory for this driver.
> type Object: AllocImpl;
>
> - /// The type used to represent a DRM File (client)
> - type File: drm::file::DriverFile;
> + /// The type used to represent a DRM File (client).
> + ///
> + /// File data may borrow from [`RegistrationData`](Driver::RegistrationData). File data is
> + /// guaranteed to be dropped before registration data, either when the file is closed or
> + /// when the device is unregistered, whichever comes first.
> + ///
> + /// Drivers implement [`DriverFile`](drm::file::DriverFile) for their file data type.
> + type File<'a>: 'a;
>
> /// The bus device type of the parent device that the DRM device is associated with.
> type ParentDevice<Ctx: device::DeviceContext>: device::AsBusDevice<Ctx>;
[ ... ]
> diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs
> index bd5e4ca2977fd..2dd0e61718fbd 100644
> --- a/rust/kernel/drm/file.rs
> +++ b/rust/kernel/drm/file.rs
> @@ -8,36 +8,66 @@
[ ... ]
> /// Trait that must be implemented by DRM drivers to represent a DRM File (a client instance).
> -pub trait DriverFile {
> +///
> +/// The lifetime `'a` allows the file data to borrow from
> +/// [`RegistrationData`](drm::Driver::RegistrationData).
> +pub trait DriverFile<'a>: Sized {
> /// The parent `Driver` implementation for this `DriverFile`.
> type Driver: drm::Driver;
[ ... ]
> @@ -45,60 +75,110 @@ pub(super) fn as_raw(&self) -> *mut bindings::drm_file {
> self.0.get()
> }
>
[ ... ]
> + /// Access the driver file data through a closure.
> + ///
> + /// The closure receives a pinned reference to the file data.
> + ///
> + /// The outer reference carries the `&self` lifetime while the inner type carries the HRTB
> + /// lifetime `'a`, implying `'a` outlives `&self`. This allows the closure to coerce covariant
> + /// sub-fields (e.g. `&'a T` to the caller's lifetime) and return them directly in `R`.
> + #[inline]
> + pub fn inner_with<'this, R, F>(&'this self, f: F) -> R
> + where
> + F: for<'a> FnOnce(Pin<&'this D::File<'a>>) -> R,
> + {
> + // SAFETY: By the type invariants, `self.as_raw()` points to a valid `drm_file`.
> + let ptr: *const FileData<_> = unsafe { (*self.as_raw()).driver_priv.cast_const().cast() };
> +
> + // SAFETY:
> + // - The type invariants keep this file's pinned `FileData` allocation valid for `'this`.
> + // - The `data` field is structurally pinned.
> + // - The HRTB `for<'a>` prevents the caller from choosing a concrete lifetime, so shortening
> + // is sound regardless of variance.
> + let data: Pin<&'this D::File<'this>> = unsafe { Pin::new_unchecked(&(*ptr).data) };
> + f(data)
> + }
[Severity: Medium]
Should Driver::File<'a> and DriverFile<'a> require Send + Sync, like
Driver::Data and Driver::RegistrationData<'a>?
Without those bounds, a driver can store non-Sync or non-Send types such
as Cell or RefCell in its per-file data in safe Rust. Multiple threads
sharing a file descriptor can invoke ioctls or GEM callbacks concurrently
on the same struct drm_file and obtain simultaneous shared references to
D::File<'_> through File::inner_with() (requiring Sync), while
File::postclose_callback() or Registration::drop_file_data() can drop the
FileData allocation on a different thread than the one that opened the
file (requiring Send), causing a data race.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107021427.2105374-1-dakr@kernel.org?part=7
next prev parent reply other threads:[~2026-11-07 2:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 2:03 [PATCH v2 0/7] lifetime-parameterized DRM File private data Danilo Krummrich
2026-11-07 2:03 ` [PATCH v2 1/7] rust: drm: rename Ioctl device context to Userspace Danilo Krummrich
2026-11-11 9:21 ` Gary Guo
2026-11-07 2:03 ` [PATCH v2 2/7] rust: drm: gem: gate open/close callbacks with RegistrationGuard Danilo Krummrich
2026-11-11 9:21 ` Gary Guo
2026-11-07 2:03 ` [PATCH v2 3/7] rust: drm: move file_operations from gem to device Danilo Krummrich
2026-11-11 9:22 ` Gary Guo
2026-11-07 2:03 ` [PATCH v2 4/7] rust: fs: add iminor() helper Danilo Krummrich
2026-11-11 9:22 ` Gary Guo
2026-11-07 2:03 ` [PATCH v2 5/7] rust: drm: wrap fops open with RegistrationGuard Danilo Krummrich
2026-11-11 9:25 ` Gary Guo
2026-11-07 2:03 ` [PATCH v2 6/7] rust: drm: return impl PinInit from DriverFile::open() Danilo Krummrich
2026-11-11 9:52 ` Gary Guo
2026-11-11 17:29 ` Daniel Almeida
2026-11-07 2:03 ` [PATCH v2 7/7] rust: drm: make Driver::File lifetime-parameterized Danilo Krummrich
2026-11-07 2:34 ` sashiko-bot [this message]
2026-11-07 8:16 ` Alice Ryhl
2026-11-07 13:26 ` Danilo Krummrich
2026-11-10 20:43 ` Alice Ryhl
2026-11-11 11:08 ` Gary Guo
2026-11-11 17:30 ` Daniel Almeida
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=sashiko-outbox-202513@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=alvin.sun@linux.dev \
--cc=beata.michalska@arm.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=brauner@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=deborah.brouwer@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=j@jananu.net \
--cc=laura.nao@collabora.com \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox