From: sashiko-bot@kernel.org
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: ojeda@kernel.org, "Alexandre Courbot" <acourbot@nvidia.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 13/13] drm: nova: Use drm::Device<Registered> to access the parent bus device
Date: Sat, 20 Jun 2026 01:17:19 +0000 [thread overview]
Message-ID: <20260620011720.1B0821F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260620005431.1562115-14-dakr@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Changing the IOCTL handler signature to accept `&Device<Registered>` forces the `declare_drm_ioctls!` macro to unsafely assert registration invariants before verifying them.
--
commit ae89d443b44234dbccc8b42ac767d5eb9bdfb248
Author: Danilo Krummrich <dakr@kernel.org>
drm: nova: Use drm::Device<Registered> to access the parent bus device
This commit modifies the get_param ioctl handler to accept a
&NovaDevice<Registered> instead of &NovaDevice, avoiding the need for
storing device data.
> diff --git a/drivers/gpu/drm/nova/file.rs b/drivers/gpu/drm/nova/file.rs
> index 4c9fa409a8be8..e0e79b5719836 100644
> --- a/drivers/gpu/drm/nova/file.rs
> +++ b/drivers/gpu/drm/nova/file.rs
[ ... ]
> @@ -23,14 +29,13 @@ fn open(_dev: &NovaDevice) -> Result<Pin<KBox<Self>>> {
> impl File {
> /// IOCTL: get_param: Query GPU / driver metadata.
> pub(crate) fn get_param(
> - dev: &NovaDevice,
> + dev: &NovaDevice<Registered>,
[Severity: High]
Does changing the ioctl handler signature to accept &Device<Registered>
cause the declare_drm_ioctls! macro to unsafely assert registration
invariants before verifying them?
The declare_drm_ioctls! macro instantiates a reference to the DRM device
using Device::from_raw(raw_dev). Because of the type-inference anchor
let _ = || { $func(dev, ...) }, changing the first parameter to
&NovaDevice<Registered> causes from_raw to be invoked with the Registered
context type.
The safety contract of from_raw requires callers to promise that any type
invariants of the generic context C are upheld. The Registered context
guarantees that the DRM device is currently registered and its parent bus
device is bound.
However, the macro calls from_raw before acquiring the RegistrationGuard,
which verifies via drm_dev_enter that the device hasn't been unplugged:
rust/kernel/drm/ioctl.rs:declare_drm_ioctls!() {
...
let dev = $crate::drm::device::Device::from_raw(raw_dev);
...
}
If the device is concurrently unplugged between drm_ioctl's initial check
and from_raw, the invariant is violated, which breaks the from_raw safety
contract and could cause undefined behavior.
Would it be safer for the handler to continue accepting &NovaDevice (the
Normal context) and call dev.registration_guard() internally to obtain a
Registered reference?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260620005431.1562115-1-dakr@kernel.org?part=13
next prev parent reply other threads:[~2026-06-20 1:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-20 0:51 [PATCH v3 00/13] rust: drm: Higher-Ranked Lifetime private data Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 01/13] rust: drm: rename Uninit DeviceContext to Normal Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 02/13] rust: drm: Add Driver::ParentDevice associated type Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 03/13] rust: drm: change default DeviceContext to Normal Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 04/13] rust: drm: restrict AlwaysRefCounted to Normal Device context Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 05/13] rust: drm: restrict AlwaysRefCounted to Normal GEM Object context Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 06/13] rust: drm: split Deref for Device context typestates Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 07/13] rust: drm: return ParentDevice from Device AsRef Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 08/13] rust: drm: add AsRef<ParentDevice<Bound>> for Device<Registered> Danilo Krummrich
2026-06-20 0:51 ` [PATCH v3 09/13] rust: drm: Add RegistrationGuard for drm_dev_enter/exit critical sections Danilo Krummrich
2026-06-20 1:12 ` sashiko-bot
2026-06-20 0:51 ` [PATCH v3 10/13] rust: drm: Add RegistrationData to drm::Driver Danilo Krummrich
2026-06-20 1:10 ` sashiko-bot
2026-06-20 0:51 ` [PATCH v3 11/13] rust: drm: Wrap ioctl dispatch in RegistrationGuard Danilo Krummrich
2026-06-20 1:13 ` sashiko-bot
2026-06-20 0:51 ` [PATCH v3 12/13] rust: drm: Pass registration data to ioctl handlers Danilo Krummrich
2026-06-20 1:16 ` sashiko-bot
2026-06-20 0:51 ` [PATCH v3 13/13] drm: nova: Use drm::Device<Registered> to access the parent bus device Danilo Krummrich
2026-06-20 1:17 ` sashiko-bot [this message]
2026-06-20 16:52 ` [PATCH v3 00/13] rust: drm: Higher-Ranked Lifetime private data Danilo Krummrich
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=20260620011720.1B0821F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=acourbot@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=sashiko-reviews@lists.linux.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 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.