mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jiwoo Kim <arpe1618@gmail.com>
To: Alessio Belle <alessio.belle@imgtec.com>,
	Luigi Santivetti <luigi.santivetti@imgtec.com>,
	Donald Robson <donald.robson@imgtec.com>
Cc: Matt Coster <opensource@mtcoster.net>,
	Sarah Walker <sarah.walker@imgtec.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>,
	imagination@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH] drm/imagination: Flush the MMU caches after unmaps done by a map
Date: Sat, 14 Nov 2026 15:24:48 +0900	[thread overview]
Message-ID: <20261114062448.1513-1-arpe1618@gmail.com> (raw)

pvr_mmu_op_context_destroy() flushes the MMU caches right away for
unmap operations, but defers the flush for map operations, which it
tells apart by op_ctx->map.sgt being set.

A DRM_IOCTL_PVR_VM_MAP over a range that overlaps existing mappings
unmaps those through the gpuva unmap and remap callbacks, with the op
context of the map operation. The flush for these unmaps is then
deferred like for a plain map, although the page tables that the
unmaps emptied are freed in pvr_mmu_op_context_destroy(), and a mapping
that is replaced entirely no longer holds a reference to its BO. Until
the next call to pvr_mmu_flush_exec(), the MMU caches can still refer
to the freed page tables and to the pages that were mapped there.

Record in the op context that pvr_mmu_unmap() was called with it, and
flush the caches right away in that case as well, before the emptied
page tables are freed, as is already done for unmap operations and as
the comment of pvr_mmu_flush_exec() requires for unmaps.

This was found with an AI coding assistant, which also drafted this
patch and its changelog. It has not been reproduced, and the change
has only been compile-tested.

Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code")
Cc: stable@vger.kernel.org
Signed-off-by: Jiwoo Kim <arpe1618@gmail.com>
---
This is about the existing DRM_IOCTL_PVR_VM_MAP path. Gyeyoung Baek's
VM_BIND series reworks how map and unmap use the op context, and this
patch does not depend on it. The sashiko review of 5/6 there raises a
related question for the new asynchronous path (BO pages freed before
the MMU flush):
https://lore.kernel.org/r/20261108-pvr-vm-bind-v2-0-730103d2cc9a@gmail.com

 drivers/gpu/drm/imagination/pvr_mmu.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imagination/pvr_mmu.c b/drivers/gpu/drm/imagination/pvr_mmu.c
index 67e73d7d5d0e..84a58ab2ab75 100644
--- a/drivers/gpu/drm/imagination/pvr_mmu.c
+++ b/drivers/gpu/drm/imagination/pvr_mmu.c
@@ -1444,6 +1444,13 @@ struct pvr_mmu_op_context {
 		 * ops. Linked list empty at creation.
 		 */
 		struct pvr_page_table_l0 *l0_free_tables;
+
+		/**
+		 * @unmap.unmapped: Set once pvr_mmu_unmap() has been called
+		 * with this op context, which also happens in a map operation
+		 * that replaces existing mappings.
+		 */
+		bool unmapped;
 	} unmap;
 
 	/**
@@ -2293,8 +2300,12 @@ void pvr_mmu_op_context_destroy(struct pvr_mmu_op_context *op_ctx)
 
 	pvr_mmu_op_context_sync(op_ctx);
 
-	/* Unmaps should be flushed immediately. Map flushes can be deferred. */
-	if (flush_caches && !op_ctx->map.sgt)
+	/*
+	 * Unmaps should be flushed immediately, and that includes the ones done
+	 * by a map operation that replaces existing mappings: the page tables
+	 * they emptied are freed below. Map flushes can be deferred.
+	 */
+	if ((flush_caches && !op_ctx->map.sgt) || op_ctx->unmap.unmapped)
 		pvr_mmu_flush_exec(op_ctx->mmu_ctx->pvr_dev, true);
 
 	while (op_ctx->map.l0_prealloc_tables) {
@@ -2486,6 +2497,8 @@ int pvr_mmu_unmap(struct pvr_mmu_op_context *op_ctx, u64 device_addr, u64 size)
 	if (err)
 		return err;
 
+	op_ctx->unmap.unmapped = true;
+
 	return pvr_mmu_op_context_unmap_curr_page(op_ctx,
 						  size >> PVR_DEVICE_PAGE_SHIFT);
 }

base-commit: d48ea86919434695da12d280dccab72b094397e1
-- 
2.43.0


                 reply	other threads:[~2026-11-14  6:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261114062448.1513-1-arpe1618@gmail.com \
    --to=arpe1618@gmail.com \
    --cc=airlied@gmail.com \
    --cc=alessio.belle@imgtec.com \
    --cc=donald.robson@imgtec.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imagination@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luigi.santivetti@imgtec.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=opensource@mtcoster.net \
    --cc=sarah.walker@imgtec.com \
    --cc=simona@ffwll.ch \
    --cc=stable@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®