From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Thomas Zimmermann <tzimmermann@suse.de>,
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, 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
Subject: Re: [10/13] drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local()
Date: Tue, 12 Mar 2024 06:36:31 +0800 [thread overview]
Message-ID: <83e2d77c-d12b-4f4f-a759-8e97fd86eff5@linux.dev> (raw)
In-Reply-To: <20240227113853.8464-11-tzimmermann@suse.de>
Hi,
On 2024/2/27 18:14, Thomas Zimmermann wrote:
> 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;
Then, please remove the local variable 'dst' (struct iosys_map) at here.
As you said, the returned iosys_map is another copy of the original backup,
we can play with this local variable at will, there no need to duplicate
another time again.
I have modified and tested with fbdev generic, no problem. With this trivial
issue resolved. For fbdev-generic:
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
next prev parent reply other threads:[~2024-03-11 22:46 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 ` [PATCH 10/13] drm/fbdev-generic: Fix locking with drm_client_buffer_vmap_local() Thomas Zimmermann
2024-03-11 22:36 ` Sui Jingfeng [this message]
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=83e2d77c-d12b-4f4f-a759-8e97fd86eff5@linux.dev \
--to=sui.jingfeng@linux.dev \
--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=sumit.semwal@linaro.org \
--cc=tzimmermann@suse.de \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).