From: sashiko-bot@kernel.org
To: "Rob Clark" <robin.clark@oss.qualcomm.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFT 4/5] drm/msm: Convert iommu map/unmap to helpers
Date: Tue, 06 Oct 2026 13:25:44 +0000 [thread overview]
Message-ID: <20261006132545.8BFD51F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261006131000.81501-5-robin.clark@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] msm: missing TLB flush in unmap sequence causes GPU UAF
- [Low] msm: build failure due to undefined __do_map and __do_unmap
--
commit a6f7885817ad9924dcb4d6924c8061a9096367bc
Author: Rob Clark <robin.clark@oss.qualcomm.com>
Subject: drm/msm: Convert iommu map/unmap to helpers
This patch converts the msm iommu map and unmap paths to use new helpers.
It replaces calls to iommu_map_sgtable() and iommu_unmap() with __do_map()
and __do_unmap(), utilizing __map_iommu() and __unmap_iommu() callbacks.
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index da6782fca6bd2..03acc851c5e6d 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
[ ... ]
> @@ -684,12 +684,27 @@ static void msm_iommu_detach(struct msm_mmu *mmu)
> iommu_detach_device(iommu->domain, mmu->dev);
> }
>
> +static size_t
> +__unmap_iommu(void *arg, u64 iova, size_t pgsize, size_t pgcount)
> +{
> + struct iommu_domain *domain = arg;
> + return domain->ops->unmap_pages(domain, iova, pgsize, pgcount, NULL);
> +}
[Severity: Critical]
By passing NULL for iotlb_gather, does this bypass the IOMMU driver's TLB
gathering and flushing mechanism?
When iommu_unmap() was previously used, it provided an iotlb_gather
structure and followed up with a synchronous TLB flush. Since this code is
invoked from msm_iommu_unmap(), leaving the TLB unflushed might retain
stale translations in hardware.
Can this lead to a use-after-free regression if the physical pages are
later reallocated and accessed by the GPU through the stale TLB entries?
> +
> +static int
> +__map_iommu(void *arg, phys_addr_t paddr, u64 iova, size_t pgsize,
[ ... ]
> @@ -697,23 +712,18 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
> if (iova & BIT_ULL(48))
> iova |= GENMASK_ULL(63, 49);
>
> - ret = iommu_map_sgtable(iommu->domain, iova, sgt, prot);
> - if (ret < 0)
> - return ret;
> -
> - return (ret == len) ? 0 : -EINVAL;
> + return __do_map(domain->pgsize_bitmap, iova, sgt, off, len, prot,
> + domain, __map_iommu, __unmap_iommu);
> }
[Severity: Low]
Is __do_map() defined anywhere in the tree?
It appears this replaces iommu_map_sgtable() with a call to __do_map(),
but there is no declaration or definition of __do_map() available.
Does this cause an implicit declaration compile error when building with
DRM_MSM enabled?
>
> static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova, size_t len)
> {
> - struct msm_iommu *iommu = to_msm_iommu(mmu);
> + struct iommu_domain *domain = to_msm_iommu(mmu)->domain;
>
> if (iova & BIT_ULL(48))
> iova |= GENMASK_ULL(63, 49);
>
> - iommu_unmap(iommu->domain, iova, len);
> -
> - return 0;
> + return __do_unmap(domain->pgsize_bitmap, iova, len, domain, __unmap_iommu);
> }
[Severity: Low]
Similar to the mapping path, is __do_unmap() actually defined?
It looks like the change from iommu_unmap() to __do_unmap() will fail to
compile due to a missing definition.
Additionally, if __do_unmap() simply invokes __unmap_iommu() and returns,
is the required TLB flush completely missing from this unmap sequence?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261006131000.81501-5-robin.clark@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-10-06 13:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 13:09 [RFT 0/5] drm/msm: DMABUF_DEBUG fixes Rob Clark
2026-10-06 13:09 ` [RFT 1/5] drm/msm: Cleanup if pages_to_sg() fails Rob Clark
2026-10-06 13:09 ` [RFT 2/5] drm/msm/gem: dma_map/unmap_sgtable() Rob Clark
2026-10-06 13:09 ` [RFT 3/5] drm/msm: Extract out map/unmap helpers Rob Clark
2026-10-06 13:19 ` sashiko-bot
2026-10-07 5:19 ` Karl Mehltretter
2026-10-07 15:13 ` Rob Clark
2026-10-06 13:09 ` [RFT 4/5] drm/msm: Convert iommu map/unmap to helpers Rob Clark
2026-10-06 13:25 ` sashiko-bot [this message]
2026-10-07 5:23 ` Karl Mehltretter
2026-10-07 15:14 ` Rob Clark
2026-10-06 13:09 ` [RFT 5/5] drm/msm: Convert map helper to use dma-address Rob Clark
2026-10-07 13:15 ` [RFT 0/5] drm/msm: DMABUF_DEBUG fixes Jianfeng Liu
2026-10-07 15:54 ` Rob Clark
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=20261006132545.8BFD51F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=robin.clark@oss.qualcomm.com \
--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.