All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Karl Mehltretter" <kmehltretter@gmail.com>
Cc: dri-devel@lists.freedesktop.org, media-ci@linuxtv.org
Subject: Re: [RFC PATCH 1/2] iommu: Add iommu_map_sgtable_dma()
Date: Fri, 09 Oct 2026 00:31:50 +0000	[thread overview]
Message-ID: <sashiko-outbox-164674@kernel.org> (raw)
In-Reply-To: <20261009002114.67851-2-kmehltretter@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] iommu: unaligned len triggers un-ratelimited pr_err() log spam in iommu_map_sgtable_dma
--

commit b1535b935267283d387d7d45e27e3ad27be6e57f
Author: Karl Mehltretter <kmehltretter@gmail.com>

iommu: Add iommu_map_sgtable_dma()

This commit adds an iommu-dma helper to map a live attachment into another
domain by translating through the device's default DMA domain.

> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 58c624513cd43..b9a1f91ec5dbb 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
[ ... ]
> +ssize_t iommu_map_sgtable_dma(struct iommu_domain *domain, unsigned long iova,
> +			      struct device *dev, struct sg_table *sgt,
> +			      int prot)
> +{
> +	struct iommu_domain *dma_domain;
> +	size_t len = 0, mapped = 0, total = 0;
> +	struct scatterlist *sg;
> +	size_t granule, target_granule;
[ ... ]
> +	target_granule = 1UL << __ffs(domain->pgsize_bitmap);
> +	if (!use_dma_iommu(dev))
> +		return -EOPNOTSUPP;
> +	dma_domain = iommu_get_dma_domain(dev);
> +	if (!dma_domain || !dma_domain->pgsize_bitmap)
> +		return -EOPNOTSUPP;
> +	granule = min(target_granule,
> +		      1UL << __ffs(dma_domain->pgsize_bitmap));
[ ... ]
> +	for_each_sgtable_dma_sg(sgt, sg, i) {
> +		dma_addr_t dma_addr = sg_dma_address(sg);
> +		size_t dma_len = sg_dma_len(sg);
> +
> +		while (dma_len) {
> +			phys_addr_t next;
> +			phys_addr_t phys;
> +
> +			phys = iommu_iova_to_phys(dma_domain, dma_addr);
[ ... ]
> +			if (len && phys != next) {
> +				ret = iommu_map_nosync(domain, iova + mapped,
> +						       start, len, prot,
> +						       GFP_KERNEL);

[Severity: Medium]
Can this result in un-ratelimited kernel log spam if `len` is not aligned to
the target domain's minimum page size?

If `dma_domain` has a smaller minimum page size than the target `domain`,
`granule` will be strictly less than `target_granule`. If the DMA-BUF backing
memory is fragmented at `granule` boundaries, `phys != next` will evaluate
to true at an offset aligned to `granule` but potentially unaligned to
`target_granule`.

When `iommu_map_nosync()` is called with this unaligned `len`, it eventually
reaches `__iommu_map_domain_pgtbl()` in drivers/iommu/iommu.c, which logs an
un-ratelimited error:

drivers/iommu/iommu.c:__iommu_map_domain_pgtbl() {
	...
	if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
		pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz 0x%x\n",
		       iova, &paddr, size, min_pagesz);
		return -EINVAL;
	}
	...
}

Could a heavily fragmented DMA-BUF provided by userspace (e.g., via a DRM
ioctl) repeatedly trigger this path and flood the kernel log?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009002114.67851-1-kmehltretter@gmail.com?part=1

  reply	other threads:[~2026-10-09  0:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  0:21 [RFC PATCH 0/2] iommu, drm/rockchip: Map private-domain imports from DMA addresses Karl Mehltretter
2026-10-09  0:21 ` Karl Mehltretter
2026-10-09  0:21 ` [RFC PATCH 1/2] iommu: Add iommu_map_sgtable_dma() Karl Mehltretter
2026-10-09  0:21   ` Karl Mehltretter
2026-10-09  0:31   ` sashiko-bot [this message]
2026-10-09 14:43   ` Jason Gunthorpe
2026-10-09 14:43     ` Jason Gunthorpe
2026-10-09  0:21 ` [RFC PATCH 2/2] drm/rockchip: Map imported buffers from DMA addresses Karl Mehltretter
2026-10-09  0:21   ` Karl Mehltretter
2026-10-09  0:31   ` sashiko-bot
2026-10-09 13:45 ` [RFC PATCH 0/2] iommu, drm/rockchip: Map private-domain imports " Robin Murphy
2026-10-09 13:45   ` Robin Murphy

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-164674@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kmehltretter@gmail.com \
    --cc=media-ci@linuxtv.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.