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: Mon, 4 Nov 2024 12:16:46 +0100 [thread overview]
Message-ID: <20241104121646.687cae93@collabora.com> (raw)
In-Reply-To: <40c9a0a3-81e4-4ecc-b9a0-d55523f5f594@arm.com>
Hi Akash,
On Thu, 31 Oct 2024 21:42:27 +0000
Akash Goel <akash.goel@arm.com> wrote:
> I assume you also reckon that there is a potential problem here for arm64.
It impacts any system that's not IO-coherent I would say, and this
comment seems to prove this is a known issue [3].
>
> Fully agree with your suggestion that the handling needs to be at the
> drm_gem_shmem level. I was not sure if we really need to do anything, as
> I didn't observe any overwrite issue during the testing. So thought
> better to limit the change to Panthor and get some feedback.
Actually, I wonder if PowerVR isn't papering over the same issue with
[1], so it looks like at least two drivers would benefit from a fix at
the drm_gem_shmem level.
>
> shmem calls 'flush_dcache_folio()' after clearing the pages but that
> just clears the 'PG_dcache_clean' bit and CPU cache is not cleaned
> immediately.
>
> I realize that this patch is not foolproof, as Userspace can try to
> populate the BO from CPU side before mapping it on the GPU side.
>
> Not sure if we also need to consider the case when shmem pages are
> swapped out. Don't know if there could be a similar situation of dirty
> cachelines after the swap in.
I think we do. We basically need to flush CPU caches any time
pages are [re]allocated, because the shmem layer will either zero-out
(first allocation) or populate (swap-in) in that path, and in both
cases, it involves a CPU copy to a cached mapping.
>
> Also not sure if dma_sync_sgtable_for_device() can be called from
> drm_gem_shmem_get_pages() as the sg_table won't be available at that point.
Okay, that's indeed an issue. Maybe we should tie the sgt allocation to
the pages allocation, as I can't think of a case where we would
allocate pages without needing the sg table that goes with it. And if
there are driver that want the sgt to be lazily allocated, we can
always add a drm_gem_shmem_object::lazy_sgt_alloc flag.
Regards,
Boris
[1]https://elixir.bootlin.com/linux/v6.11.6/source/drivers/gpu/drm/imagination/pvr_gem.c#L363
[2]https://elixir.bootlin.com/linux/v6.11.6/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L177
[3]https://elixir.bootlin.com/linux/v6.11.6/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L185
next prev parent reply other threads:[~2024-11-04 11:16 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
2024-10-31 21:42 ` Akash Goel
2024-11-04 11:16 ` Boris Brezillon [this message]
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=20241104121646.687cae93@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox