From: sashiko-bot@kernel.org
To: "Arun Iyengar" <aiyengar1990@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/7] drm/panfrost: Give back the pages of a heap chunk that failed to map
Date: Tue, 10 Nov 2026 08:03:53 +0000 [thread overview]
Message-ID: <sashiko-outbox-206561@kernel.org> (raw)
In-Reply-To: <20261110-panfrost-long-jobs-v1-3-24508939ae8d@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/panfrost: partial cleanup of >2MB folios in
panfrost_heap_put_chunk()
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Critical] drm/panfrost: NULL pointer dereference in
panfrost_gem_sync() on heap BOs [1]
--
commit afb30e586f33dffb885482044302a7b61909475c
Author: Arun Iyengar <aiyengar1990@gmail.com>
drm/panfrost: Give back the pages of a heap chunk that failed to map
This commit adds panfrost_heap_put_chunk() to release folios and clear page
array entries when mapping a 2 MB heap chunk fails in
panfrost_mmu_map_fault_addr().
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index ba37da4992307..13728b0c46efc 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -597,6 +597,28 @@ addr_to_mapping(struct panfrost_device *pfdev, int as, u64 addr)
>
> #define NUM_FAULT_PAGES (SZ_2M / PAGE_SIZE)
>
> +static void panfrost_heap_put_chunk(struct page **pages, pgoff_t start,
> + pgoff_t end)
> +{
> + pgoff_t pg = start;
> +
> + while (pg < end) {
> + struct folio *folio;
> + pgoff_t n;
> +
> + if (!pages[pg]) {
> + pg++;
> + continue;
> + }
> +
> + folio = page_folio(pages[pg]);
> + n = folio_nr_pages(folio);
> + for (pgoff_t i = 0; i < n && pg < end; i++)
> + pages[pg++] = NULL;
> + folio_put(folio);
> + }
> +}
> +
> static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as,
> u64 addr)
> {
> @@ -671,7 +693,7 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as,
> folio = shmem_read_folio(mapping, pg);
> if (IS_ERR(folio)) {
> ret = PTR_ERR(folio);
> - goto err_unlock;
> + goto err_put_chunk;
> }
[Severity: Critical]
This problem wasn't introduced by this patch, but can calling
panfrost_gem_sync() on a heap BO [1] cause a NULL pointer dereference?
On coherent devices (pfdev->coherent is true), should_map_wc() returns
false, so panfrost_gem_sync() does not return early on shmem->map_wc and
calls drm_gem_shmem_get_pages_sgt():
drivers/gpu/drm/panfrost/panfrost_gem.c:panfrost_gem_sync() {
...
if (shmem->map_wc)
return 0;
/* Nothing to do if the size is zero. */
if (size == 0)
return 0;
sgt = drm_gem_shmem_get_pages_sgt(shmem);
...
}
If a heap BO has already faulted in at least one chunk, bo->base.pages is
non-NULL with NULL entries for unfaulted chunks and bo->base.sgt is NULL, so
drm_gem_shmem_get_pages_sgt() passes the sparse bo->base.pages array to
drm_prime_pages_to_sg() and dereferences NULL page pointers. Conversely, if
panfrost_gem_sync() runs before the first GPU fault on the heap BO,
drm_gem_shmem_get_pages_sgt() populates bo->base.pages while leaving
bo->sgts NULL, and a later fault in panfrost_mmu_map_fault_addr() skips
allocating bo->sgts and dereferences NULL when indexing bo->sgts.
[ ... ]
> @@ -720,6 +742,14 @@ static int panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int as,
> dma_unmap_sgtable(pfdev->base.dev, sgt, DMA_BIDIRECTIONAL, 0);
> err_map:
> sg_free_table(sgt);
> +err_put_chunk:
> + /*
> + * Give back the folios read for this chunk, so that the next fault in
> + * it (the chunk has no sg table yet) starts from an empty page range
> + * instead of finding it partly owned.
> + */
> + panfrost_heap_put_chunk(pages, page_offset,
> + min_t(pgoff_t, page_offset + NUM_FAULT_PAGES, nr_pages));
[Severity: Medium]
Can panfrost_heap_put_chunk() leave dangling page pointers or drop an active
folio reference when shmem_read_folio() returns a folio larger than 2 MB?
With PAGE_SIZE > 4 KB (such as 16 KB or 64 KB pages on arm64) and
transparent hugepages enabled, shmem_read_folio() on the huge=within_size
mount can return a folio with folio_nr_pages(folio) > NUM_FAULT_PAGES. The
fill loop in panfrost_mmu_map_fault_addr() aligns pg down to the folio
boundary and populates pages[] across the entire folio:
drivers/gpu/drm/panfrost/panfrost_mmu.c:panfrost_mmu_map_fault_addr() {
...
pg &= ~(folio_nr_pages(folio) - 1);
for (u32 i = 0; i < folio_nr_pages(folio) && pg < nr_pages; i++) {
if (pages[pg])
already_owned = true;
pages[pg++] = folio_page(folio, i);
}
}
On error, panfrost_heap_put_chunk() only clears pages[] within
[page_offset, page_offset + NUM_FAULT_PAGES) before calling
folio_put(folio). Any pages[] slots populated for that folio in adjacent
2 MB chunks remain non-NULL after the folio reference is dropped (or if an
adjacent chunk was already mapped and the duplicate reference was dropped via
already_owned, folio_put(folio) drops the mapped chunk's reference), leading
to a second folio_put() in drm_gem_put_pages() when the BO is freed and a
folio use-after-free.
[1] https://sashiko.dev/#/bug/linux-fe4f761b-d268-4774-87c0-3f0de658e362
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110-panfrost-long-jobs-v1-0-24508939ae8d@gmail.com?part=3
next prev parent reply other threads:[~2026-11-10 8:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 7:44 [PATCH 0/7] drm/panfrost: Resume long jobs instead of resetting, and mapping error path fixes Arun Iyengar
2026-11-10 7:44 ` Arun Iyengar via B4 Relay
2026-11-10 7:44 ` [PATCH 1/7] drm/panfrost: Don't WARN when a GEM mapping cannot get its pages Arun Iyengar
2026-11-10 7:44 ` Arun Iyengar via B4 Relay
2026-11-10 7:44 ` [PATCH 2/7] drm/panfrost: Unwind a failed GPU mapping without dropping " Arun Iyengar
2026-11-10 7:44 ` Arun Iyengar via B4 Relay
2026-11-10 7:44 ` [PATCH 3/7] drm/panfrost: Give back the pages of a heap chunk that failed to map Arun Iyengar
2026-11-10 7:44 ` Arun Iyengar via B4 Relay
2026-11-10 8:03 ` sashiko-bot [this message]
2026-11-10 7:44 ` [PATCH 4/7] drm/panfrost: Don't resume a soft-stopped job after a GPU reset Arun Iyengar
2026-11-10 7:44 ` Arun Iyengar via B4 Relay
2026-11-10 7:58 ` sashiko-bot
2026-11-10 7:45 ` [PATCH 5/7] drm/panfrost: Wait for the soft-stopped slots with the live slot status Arun Iyengar
2026-11-10 7:45 ` Arun Iyengar via B4 Relay
2026-11-10 7:45 ` [PATCH 6/7] drm/panfrost: Soft-stop and resume a job that outlives the timeout Arun Iyengar
2026-11-10 7:45 ` Arun Iyengar via B4 Relay
2026-11-10 8:14 ` sashiko-bot
2026-11-10 7:45 ` [PATCH 7/7] drm/panfrost: Name the BOs around an unhandled page fault Arun Iyengar
2026-11-10 7:45 ` Arun Iyengar via B4 Relay
2026-11-10 8:10 ` sashiko-bot
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=sashiko-outbox-206561@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aiyengar1990@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.