From: Boris Brezillon <boris.brezillon@collabora.com>
To: Akash Goel <akash.goel@arm.com>
Cc: liviu.dudau@arm.com, steven.price@arm.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
mihail.atanassov@arm.com, ketil.johnsen@arm.com,
florent.tomasin@arm.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
daniel@ffwll.ch, nd@arm.com
Subject: Re: [PATCH 3/3] drm/panthor: Prevent potential overwrite of buffer objects
Date: Thu, 24 Oct 2024 17:39:35 +0200 [thread overview]
Message-ID: <20241024173935.6430159e@collabora.com> (raw)
In-Reply-To: <20241024145432.934086-4-akash.goel@arm.com>
On Thu, 24 Oct 2024 15:54:32 +0100
Akash Goel <akash.goel@arm.com> wrote:
> All CPU mappings are forced as uncached for Panthor buffer objects when
> system(IO) coherency is disabled. Physical backing for Panthor BOs is
> allocated by shmem, which clears the pages also after allocation. But
> there is no explicit cache flush done after the clearing of pages.
> So it could happen that there are dirty cachelines in the CPU cache
> for the BOs, when they are accessed from the CPU side through uncached
> CPU mapping, and the eviction of cachelines overwrites the data of BOs.
Hm, this looks like something that should be handled at the
drm_gem_shmem level when drm_gem_shmem_object::map_wc=true, as I
suspect other drivers can hit the same issue (I'm thinking of panfrost
and lima, but there might be others).
>
> This commit tries to avoid the potential overwrite scenario.
>
> Signed-off-by: Akash Goel <akash.goel@arm.com>
> ---
> drivers/gpu/drm/panthor/panthor_gem.h | 10 ++++++++++
> drivers/gpu/drm/panthor/panthor_mmu.c | 5 +++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h
> index e43021cf6d45..4b0f43f1edf1 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.h
> +++ b/drivers/gpu/drm/panthor/panthor_gem.h
> @@ -46,6 +46,16 @@ struct panthor_gem_object {
>
> /** @flags: Combination of drm_panthor_bo_flags flags. */
> u32 flags;
> +
> + /**
> + * @cleaned: The buffer object pages have been cleaned.
> + *
> + * There could be dirty CPU cachelines for the pages of buffer object
> + * after allocation, as shmem will zero out the pages. The cachelines
> + * need to be cleaned if the pages are going to be accessed with an
> + * uncached CPU mapping.
> + */
> + bool cleaned;
> };
>
> /**
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index f522a116c1b1..d8cc9e7d064e 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -1249,6 +1249,11 @@ static int panthor_vm_prepare_map_op_ctx(struct panthor_vm_op_ctx *op_ctx,
>
> op_ctx->map.sgt = sgt;
>
> + if (bo->base.map_wc && !bo->cleaned) {
> + dma_sync_sgtable_for_device(vm->ptdev->base.dev, sgt, DMA_TO_DEVICE);
> + bo->cleaned = true;
> + }
> +
> preallocated_vm_bo = drm_gpuvm_bo_create(&vm->base, &bo->base.base);
> if (!preallocated_vm_bo) {
> if (!bo->base.base.import_attach)
next prev parent reply other threads:[~2024-10-24 15:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 14:54 [PATCH 0/3] drm/panthor: Coherency related fixes Akash Goel
2024-10-24 14:54 ` [PATCH 1/3] drm/panthor: Update memattr programing to align with GPU spec Akash Goel
2024-10-24 15:49 ` Boris Brezillon
2024-10-25 9:24 ` Liviu Dudau
2024-10-25 12:31 ` Boris Brezillon
2024-10-25 10:03 ` Steven Price
2024-10-24 14:54 ` [PATCH 2/3] drm/panthor: Explicitly set the coherency mode Akash Goel
2024-10-24 15:51 ` Boris Brezillon
2024-10-25 9:29 ` Liviu Dudau
2024-10-25 10:03 ` Steven Price
2024-10-24 14:54 ` [PATCH 3/3] drm/panthor: Prevent potential overwrite of buffer objects Akash Goel
2024-10-24 15:39 ` Boris Brezillon [this message]
2024-10-31 21:42 ` Akash Goel
2024-11-04 11:16 ` Boris Brezillon
2024-11-04 12:49 ` Akash Goel
2024-11-04 13:41 ` Boris Brezillon
2024-10-30 15:46 ` [PATCH 0/3] drm/panthor: Coherency related fixes Boris Brezillon
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=20241024173935.6430159e@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.com \
--cc=akash.goel@arm.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=florent.tomasin@arm.com \
--cc=ketil.johnsen@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mihail.atanassov@arm.com \
--cc=mripard@kernel.org \
--cc=nd@arm.com \
--cc=steven.price@arm.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.