All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	"Abhinav Kumar" <abhinav.kumar@linux.dev>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Anna Maniscalco" <anna.maniscalco2000@gmail.com>,
	"Antonino Maniscalco" <antomani103@gmail.com>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Dmitry Baryshkov" <lumag@kernel.org>,
	"Jessica Zhang" <jesszhan0024@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	"Lyude Paul" <lyude@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Marijn Suijten" <marijn.suijten@somainline.org>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Rob Clark" <robin.clark@oss.qualcomm.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Sean Paul" <sean@poorly.run>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Steven Price" <steven.price@arm.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: [PATCH v3 5/8] drm/msm: use DRM_GPUVM_RESV_PROTECTED for VM_BIND VMs
Date: Thu,  1 Oct 2026 15:06:29 -0700	[thread overview]
Message-ID: <20261001220632.3190896-6-matthew.brost@intel.com> (raw)
In-Reply-To: <20261001220632.3190896-1-matthew.brost@intel.com>

msm_gem_vm_create() creates every drm_gpuvm without
DRM_GPUVM_RESV_PROTECTED, on the grounds that it makes
drm_gpuvm_bo_evict() lose track of evicted external objects. It does not:
drm_gpuvm_bo_evict() still sets drm_gpuvm_bo::evicted on an extobj, and
drm_gpuvm_prepare_objects() moves any such extobj onto the evicted list
before drm_gpuvm_validate() looks at it. The VM_BIND submit path always
calls the two in that order.

Userspace managed VMs already touch the extobj and evicted lists only
with the VM's resv held: VMAs are created and linked by VM_BIND under
the VM resv, msm_gem_vma_close() asserts it, and every drm_gpuvm_bo_put()
which can drop the last reference of a VM_BIND vm_bo runs with it held,
via msm_gem_lock_vm_and_obj(), with_vm_locks() or the object free path.
The internal spinlocks buy nothing there, so set
DRM_GPUVM_RESV_PROTECTED for those VMs.

Kernel managed VMs are left alone. The legacy submit path holds a vm_bo
reference per BO and drops it in msm_submit_retire() with only the
object's resv held, which could be the last reference once the VMA is
gone. VM_BIND contexts never get there, the previous patch having made
MSM_GEM_SUBMIT reject a submit_bo table from them.

This is also what two pass locking in drm_gpuvm requires, which a
following patch makes use of.

Cc: Abhinav Kumar <abhinav.kumar@linux.dev>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Anna Maniscalco <anna.maniscalco2000@gmail.com>
Cc: Antonino Maniscalco <antomani103@gmail.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Dmitry Baryshkov <lumag@kernel.org>
Cc: Jessica Zhang <jesszhan0024@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Marijn Suijten <marijn.suijten@somainline.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Steven Price <steven.price@arm.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Assisted-by: LLM
---
v3:
 - Rely on VM_BIND contexts not being able to pass a submit_bo table,
   now enforced by the previous patch (Sashiko)
---
 drivers/gpu/drm/msm/msm_gem_vma.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
index 1badec3caa7b..c2b2415e86c9 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -818,11 +818,19 @@ msm_gem_vm_create(struct drm_device *drm, struct msm_mmu *mmu, const char *name,
 		  u64 va_start, u64 va_size, bool managed)
 {
 	/*
-	 * We mostly want to use DRM_GPUVM_RESV_PROTECTED, except that
-	 * makes drm_gpuvm_bo_evict() a no-op for extobjs (ie. we loose
-	 * tracking that an extobj is evicted) :facepalm:
+	 * Userspace managed (VM_BIND) VMs only ever touch the gpuvm's extobj
+	 * and evicted lists with the VM's resv held, so use
+	 * DRM_GPUVM_RESV_PROTECTED for those.  drm_gpuvm_bo_evict() cannot
+	 * put an extobj on the evicted list there, but it records the
+	 * eviction and drm_gpuvm_prepare_objects() moves it onto the list
+	 * before drm_gpuvm_validate() runs, so nothing is lost.
+	 *
+	 * Kernel managed VMs keep the internal spinlocks, since the legacy
+	 * submit path can drop the last vm_bo reference with only the
+	 * object's resv held (see msm_submit_retire()).  VM_BIND contexts
+	 * cannot reach that path, as they may not pass a submit_bo table.
 	 */
-	enum drm_gpuvm_flags flags = 0;
+	enum drm_gpuvm_flags flags = managed ? 0 : DRM_GPUVM_RESV_PROTECTED;
 	struct msm_gem_vm *vm;
 	struct drm_gem_object *dummy_gem;
 	int ret = 0;
-- 
2.34.1


  parent reply	other threads:[~2026-10-01 22:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 22:06 [PATCH v3 0/8] drm/gpuvm: two pass locking for exec Matthew Brost
2026-10-01 22:06 ` [PATCH v3 1/8] drm/gpuvm: allow locking external objects in two passes Matthew Brost
2026-10-04 19:56   ` Anna Maniscalco
2026-10-01 22:06 ` [PATCH v3 2/8] drm/xe: lock the resident BOs of an exec last Matthew Brost
2026-10-01 22:06 ` [PATCH v3 3/8] drm/panthor: lock the resident BOs of a submit last Matthew Brost
2026-10-05  9:39   ` Boris Brezillon
2026-10-01 22:06 ` [PATCH v3 4/8] drm/msm: reject a submit_bo table on VM_BIND contexts Matthew Brost
2026-10-01 22:06 ` Matthew Brost [this message]
2026-10-01 22:06 ` [PATCH v3 6/8] drm/msm: lock the resident BOs of a VM_BIND submit last Matthew Brost
2026-10-04 20:29   ` Anna Maniscalco
2026-10-01 22:06 ` [PATCH v3 7/8] drm/nouveau: use DRM_GPUVM_RESV_PROTECTED Matthew Brost
2026-10-02  0:06   ` Matthew Brost
2026-10-02 20:17     ` Matthew Brost
2026-10-02  9:13   ` sashiko-bot
2026-10-06 16:50   ` Liviu Dudau
2026-10-01 22:06 ` [PATCH v3 8/8] drm/nouveau: lock the resident BOs of an exec last Matthew Brost
2026-10-01 22:29 ` ✓ CI.KUnit: success for drm/gpuvm: two pass locking for exec (rev3) Patchwork

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=20261001220632.3190896-6-matthew.brost@intel.com \
    --to=matthew.brost@intel.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=anna.maniscalco2000@gmail.com \
    --cc=antomani103@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jesszhan0024@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=lumag@kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marijn.suijten@somainline.org \
    --cc=mripard@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sean@poorly.run \
    --cc=simona@ffwll.ch \
    --cc=skhan@linuxfoundation.org \
    --cc=steven.price@arm.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.