Rust for Linux List
 help / color / mirror / Atom feed
From: Daniel Pesic <danny.pesic@gmail.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org,
	"Daniel Pesic" <danny.pesic@gmail.com>
Subject: [PATCH 2/2] rust: drm: gpuvm: call drm_gpuvm_bo_destroy_not_in_lists() in Drop
Date: Mon, 27 Jul 2026 07:11:21 -0700	[thread overview]
Message-ID: <20260727141121.11975-3-danny.pesic@gmail.com> (raw)
In-Reply-To: <20260727141121.11975-1-danny.pesic@gmail.com>

GpuVmBoAlloc's type invariant guarantees a refcount of one and absence
from the gem, extobj, and evict lists for as long as the value exists as
itself. The only way to consume it is via obtain(), which moves it out
via ManuallyDrop, so the invariant holds when Drop::drop runs. Since
this is the required precondition for
drm_gpuvm_bo_destroy_not_in_lists(), call it directly rather than going
through the deferred put, and drop the TODO.

The GEM's gpuva lock must not be held when this runs, since freeing the
last reference to the GEM object would free the lock embedded in it.
Drop::drop has a fixed safe signature, so this precondition cannot be
enforced by the type system and is documented instead, matching the
existing note on GpuVmBoAlloc::obtain(). It currently holds as
lock_gpuva()'s two call sites, in sm_ops.rs, operate on a GpuVmBo that
is already obtained and never construct or drop a GpuVmBoAlloc.

Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Daniel Pesic <danny.pesic@gmail.com>
---
 rust/kernel/drm/gpuvm/vm_bo.rs | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/rust/kernel/drm/gpuvm/vm_bo.rs b/rust/kernel/drm/gpuvm/vm_bo.rs
index a30f838c11b8..7c0f5846cf39 100644
--- a/rust/kernel/drm/gpuvm/vm_bo.rs
+++ b/rust/kernel/drm/gpuvm/vm_bo.rs
@@ -249,10 +249,14 @@ fn deref(&self) -> &GpuVmBo<T> {
 }
 
 impl<T: DriverGpuVm> Drop for GpuVmBoAlloc<T> {
+    /// Must not be dropped while holding the `drm_gem_object` gpuva lock.
     #[inline]
     fn drop(&mut self) {
-        // TODO: Call drm_gpuvm_bo_destroy_not_in_lists() directly.
-        // SAFETY: It's safe to perform a deferred put in any context.
-        unsafe { bindings::drm_gpuvm_bo_put_deferred(self.as_raw()) };
+        // SAFETY: By the type invariant, `drm_gpuvm_bo` has a refcount
+        // of one and is absent from the gem, extobj, and evict lists.
+        // Per the precondition documented in impl, the caller does not
+        // hold the object's gpuva lock. Therefore, the preconditions of
+        // `drm_gpuvm_bo_destroy_not_in_lists()` are satisfied.
+        unsafe { bindings::drm_gpuvm_bo_destroy_not_in_lists(self.as_raw()) };
     }
 }
-- 
2.55.0


      parent reply	other threads:[~2026-07-27 21:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27 14:11 [PATCH 0/2] drm/gpuvm: avoid deferred cleanup on GpuVmBoAlloc drop Daniel Pesic
2026-07-27 14:11 ` [PATCH 1/2] drm/gpuvm: export drm_gpuvm_bo_destroy_not_in_lists() Daniel Pesic
2026-07-27 14:11 ` Daniel Pesic [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=20260727141121.11975-3-danny.pesic@gmail.com \
    --to=danny.pesic@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mripard@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tamird@kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tmgross@umich.edu \
    --cc=tzimmermann@suse.de \
    --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