From: Thomas Zimmermann <tzimmermann@suse.de>
To: daniel@ffwll.ch, airlied@gmail.com, mripard@kernel.org,
maarten.lankhorst@linux.intel.com, christian.koenig@amd.com,
sumit.semwal@linaro.org, dmitry.osipenko@collabora.com,
robdclark@gmail.com, quic_abhinavk@quicinc.com,
dmitry.baryshkov@linaro.org, sean@poorly.run,
marijn.suijten@somainline.org, suijingfeng@loongson.cn,
kherbst@redhat.com, lyude@redhat.com, dakr@redhat.com,
airlied@redhat.com, kraxel@redhat.com, alexander.deucher@amd.com,
Xinhui.Pan@amd.com, zack.rusin@broadcom.com,
bcm-kernel-feedback-list@broadcom.com
Cc: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org,
virtualization@lists.linux.dev,
spice-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: [PATCH 10/13] drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()
Date: Tue, 27 Feb 2024 11:14:57 +0100 [thread overview]
Message-ID: <20240227113853.8464-11-tzimmermann@suse.de> (raw)
In-Reply-To: <20240227113853.8464-1-tzimmermann@suse.de>
Temporarily lock the fbdev buffer object during updates to prevent
memory managers from evicting/moving the buffer. Moving a buffer
object while update its content results in undefined behaviour.
Fbdev-generic updates its buffer object from a shadow buffer. Gem-shmem
and gem-dma helpers do not move buffer objects, so they are safe to be
used with fbdev-generic. Gem-vram and qxl are based on TTM, but pin
buffer objects are part of the vmap operation. So both are also safe
to be used with fbdev-generic.
Amdgpu and nouveau do not pin or lock the buffer object during an
update. Their TTM-based memory management could move the buffer object
while the update is ongoing.
The new vmap_local and vunmap_local helpers hold the buffer object's
reservation lock during the buffer update. This prevents moving the
buffer object on all memory managers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_client.c | 68 +++++++++++++++++++++++++----
drivers/gpu/drm/drm_fbdev_generic.c | 4 +-
drivers/gpu/drm/drm_gem.c | 12 +++++
include/drm/drm_client.h | 10 +++++
include/drm/drm_gem.h | 3 ++
5 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9403b3f576f7b..2cc81831236b5 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -304,6 +304,66 @@ drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height,
return ERR_PTR(ret);
}
+/**
+ * drm_client_buffer_vmap_local - Map DRM client buffer into address space
+ * @buffer: DRM client buffer
+ * @map_copy: Returns the mapped memory's address
+ *
+ * This function maps a client buffer into kernel address space. If the
+ * buffer is already mapped, it returns the existing mapping's address.
+ *
+ * Client buffer mappings are not ref'counted. Each call to
+ * drm_client_buffer_vmap_local() should be closely followed by a call to
+ * drm_client_buffer_vunmap_local(). See drm_client_buffer_vmap() for
+ * long-term mappings.
+ *
+ * The returned address is a copy of the internal value. In contrast to
+ * other vmap interfaces, you don't need it for the client's vunmap
+ * function. So you can modify it at will during blit and draw operations.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_client_buffer_vmap_local(struct drm_client_buffer *buffer,
+ struct iosys_map *map_copy)
+{
+ struct drm_gem_object *gem = buffer->gem;
+ struct iosys_map *map = &buffer->map;
+ int ret;
+
+ drm_gem_lock(gem);
+
+ ret = drm_gem_vmap(gem, map);
+ if (ret)
+ goto err_drm_gem_vmap_unlocked;
+ *map_copy = *map;
+
+ return 0;
+
+err_drm_gem_vmap_unlocked:
+ drm_gem_unlock(gem);
+ return 0;
+}
+EXPORT_SYMBOL(drm_client_buffer_vmap_local);
+
+/**
+ * drm_client_buffer_vunmap_local - Unmap DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function removes a client buffer's memory mapping established
+ * with drm_client_buffer_vunmap_local(). Calling this function is only
+ * required by clients that manage their buffer mappings by themselves.
+ */
+void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer)
+{
+ struct drm_gem_object *gem = buffer->gem;
+ struct iosys_map *map = &buffer->map;
+
+ drm_gem_vunmap(gem, map);
+ drm_gem_unlock(gem);
+}
+EXPORT_SYMBOL(drm_client_buffer_vunmap_local);
+
/**
* drm_client_buffer_vmap - Map DRM client buffer into address space
* @buffer: DRM client buffer
@@ -331,14 +391,6 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
struct iosys_map *map = &buffer->map;
int ret;
- /*
- * FIXME: The dependency on GEM here isn't required, we could
- * convert the driver handle to a dma-buf instead and use the
- * backend-agnostic dma-buf vmap support instead. This would
- * require that the handle2fd prime ioctl is reworked to pull the
- * fd_install step out of the driver backend hooks, to make that
- * final step optional for internal users.
- */
ret = drm_gem_vmap_unlocked(buffer->gem, map);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c b/drivers/gpu/drm/drm_fbdev_generic.c
index d647d89764cb9..be357f926faec 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -197,14 +197,14 @@ static int drm_fbdev_generic_damage_blit(struct drm_fb_helper *fb_helper,
*/
mutex_lock(&fb_helper->lock);
- ret = drm_client_buffer_vmap(buffer, &map);
+ ret = drm_client_buffer_vmap_local(buffer, &map);
if (ret)
goto out;
dst = map;
drm_fbdev_generic_damage_blit_real(fb_helper, clip, &dst);
- drm_client_buffer_vunmap(buffer);
+ drm_client_buffer_vunmap_local(buffer);
out:
mutex_unlock(&fb_helper->lock);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e0f80c6a7096f..d4bbc5d109c8b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1227,6 +1227,18 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
}
EXPORT_SYMBOL(drm_gem_vunmap);
+void drm_gem_lock(struct drm_gem_object *obj)
+{
+ dma_resv_lock(obj->resv, NULL);
+}
+EXPORT_SYMBOL(drm_gem_lock);
+
+void drm_gem_unlock(struct drm_gem_object *obj)
+{
+ dma_resv_unlock(obj->resv);
+}
+EXPORT_SYMBOL(drm_gem_unlock);
+
int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
{
int ret;
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index d47458ecdac46..bc0e66f9c4251 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -141,6 +141,13 @@ struct drm_client_buffer {
/**
* @gem: GEM object backing this buffer
+ *
+ * FIXME: The dependency on GEM here isn't required, we could
+ * convert the driver handle to a dma-buf instead and use the
+ * backend-agnostic dma-buf vmap support instead. This would
+ * require that the handle2fd prime ioctl is reworked to pull the
+ * fd_install step out of the driver backend hooks, to make that
+ * final step optional for internal users.
*/
struct drm_gem_object *gem;
@@ -159,6 +166,9 @@ struct drm_client_buffer *
drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32 height, u32 format);
void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct drm_rect *rect);
+int drm_client_buffer_vmap_local(struct drm_client_buffer *buffer,
+ struct iosys_map *map_copy);
+void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer);
int drm_client_buffer_vmap(struct drm_client_buffer *buffer,
struct iosys_map *map);
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 2ebec3984cd44..bae4865b2101a 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -527,6 +527,9 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj);
void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
bool dirty, bool accessed);
+void drm_gem_lock(struct drm_gem_object *obj);
+void drm_gem_unlock(struct drm_gem_object *obj);
+
int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map);
void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map);
--
2.43.2
next prev parent reply other threads:[~2024-02-27 11:39 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 10:14 [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 01/13] drm/gem-shmem: Acquire reservation lock in GEM pin/unpin callbacks Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 02/13] drm/gem-vram: " Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 03/13] drm/msm: Provide msm_gem_get_pages_locked() Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 04/13] drm/msm: Acquire reservation lock in GEM pin/unpin callback Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 05/13] drm/nouveau: Provide nouveau_bo_{pin,unpin}_locked() Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 06/13] drm/nouveau: Acquire reservation lock in GEM pin/unpin callbacks Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 07/13] drm/qxl: Provide qxl_bo_{pin,unpin}_locked() Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 08/13] drm/qxl: Acquire reservation lock in GEM pin/unpin callbacks Thomas Zimmermann
2024-02-28 3:47 ` Zack Rusin
2024-02-27 10:14 ` [PATCH 09/13] drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}() Thomas Zimmermann
2024-02-28 3:52 ` Zack Rusin
2024-03-11 21:51 ` [09/13] " Sui Jingfeng
2024-02-27 10:14 ` Thomas Zimmermann [this message]
2024-03-11 22:36 ` [10/13] drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local() Sui Jingfeng
2024-02-27 10:14 ` [PATCH 11/13] drm/client: Pin vmap'ed GEM buffers Thomas Zimmermann
2024-02-27 10:14 ` [PATCH 12/13] drm/gem-vram: Do not pin buffer objects for vmap Thomas Zimmermann
2024-02-27 10:15 ` [PATCH 13/13] drm/qxl: " Thomas Zimmermann
2024-02-27 14:03 ` [PATCH 00/13] drm: Fix reservation locking for pin/unpin and console Christian König
2024-02-27 15:42 ` Thomas Zimmermann
2024-02-27 18:14 ` Dmitry Osipenko
2024-02-27 18:33 ` Christian König
2024-02-28 8:19 ` Thomas Zimmermann
2024-03-01 16:44 ` Dmitry Osipenko
2024-02-28 3:54 ` Zack Rusin
2024-03-05 21:58 ` Dmitry Osipenko
2024-03-06 14:44 ` Thomas Zimmermann
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=20240227113853.8464-11-tzimmermann@suse.de \
--to=tzimmermann@suse.de \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=christian.koenig@amd.com \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=kherbst@redhat.com \
--cc=kraxel@redhat.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=spice-devel@lists.freedesktop.org \
--cc=suijingfeng@loongson.cn \
--cc=sumit.semwal@linaro.org \
--cc=virtualization@lists.linux.dev \
--cc=zack.rusin@broadcom.com \
/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;
as well as URLs for NNTP newsgroup(s).