NVIDIA GPU driver infrastructure
 help / color / mirror / Atom feed
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

  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