From: sashiko-bot@kernel.org
To: "Vikash Garodia" <vikash.garodia@oss.qualcomm.com>
Cc: virtualization@lists.linux.dev, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v6 1/2] iommu: use resource_size_t for reserved region length
Date: Tue, 03 Nov 2026 15:46:09 +0000 [thread overview]
Message-ID: <sashiko-outbox-195650@kernel.org> (raw)
In-Reply-To: <20261103-add_iommu_ranges-v6-1-361f3921a133@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] vfio/type1: truncation of region->length in vfio_find_dma() on 32-bit LPAE
--
commit 0e9e6ab1dd5582c6a157191dbe1e262f13c108a9
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
iommu: use resource_size_t for reserved region length
This commit widens struct iommu_resv_region.length and related helper
parameters from size_t to resource_size_t so that reserved regions of 4GiB
or larger are not truncated on 32-bit systems with LPAE.
[ ... ]
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index ef5043752a365..1d8f9381a358e 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -306,7 +306,7 @@ enum iommu_resv_type {
> struct iommu_resv_region {
> struct list_head list;
> phys_addr_t start;
> - size_t length;
> + resource_size_t length;
[Severity: Medium]
Now that region->length can hold values of 4GiB or larger on 32-bit LPAE
systems, could it still get truncated when passed to vfio_find_dma() via
vfio_iommu_type1_attach_group() -> vfio_iommu_resv_conflict()?
In drivers/vfio/vfio_iommu_type1.c, vfio_iommu_resv_conflict() passes
region->length directly to vfio_find_dma():
drivers/vfio/vfio_iommu_type1.c:vfio_iommu_resv_conflict() {
list_for_each_entry(region, resv_regions, list) {
if (region->type == IOMMU_RESV_DIRECT_RELAXABLE)
continue;
if (vfio_find_dma(iommu, region->start, region->length))
return true;
}
}
However, vfio_find_dma() still takes size as a 32-bit size_t on 32-bit LPAE
systems:
drivers/vfio/vfio_iommu_type1.c:vfio_find_dma() {
static struct vfio_dma *vfio_find_dma(struct vfio_iommu *iommu,
dma_addr_t start, size_t size)
{
struct rb_node *node = iommu->dma_list.rb_node;
WARN_ON(!size);
while (node) {
struct vfio_dma *dma = rb_entry(node, struct vfio_dma, node);
if (start + size - 1 < dma->iova)
...
}
If an IOMMU group with a reserved region of 4GiB or larger is attached to a
VFIO container on a 32-bit LPAE system, region->length will be truncated to
32 bits. When region->length is a multiple of 4GiB, size becomes 0,
triggering WARN_ON(!size) and miscomputing start + size - 1; for other
sizes >= 4GiB, the upper portion of the reserved region will not be checked
for conflicting DMA mappings.
Should the size parameter of vfio_find_dma() (or a dedicated range helper)
also be widened to resource_size_t or dma_addr_t?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261103-add_iommu_ranges-v6-0-361f3921a133@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-11-03 15:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 15:29 [PATCH v6 0/2] of_iommu: add support for "iommu-ranges" Vikash Garodia
2026-11-03 15:29 ` [PATCH v6 1/2] iommu: use resource_size_t for reserved region length Vikash Garodia
2026-11-03 15:46 ` sashiko-bot [this message]
2026-11-03 15:29 ` [PATCH v6 2/2] of: Add support for "iommu-ranges" on a device node Vikash Garodia
2026-11-03 15:49 ` sashiko-bot
2026-11-04 16:03 ` Rob Herring
2026-11-05 13:39 ` Vikash Garodia
2026-11-04 16:23 ` Bryan O'Donoghue
2026-11-05 13:41 ` Vikash Garodia
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-195650@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vikash.garodia@oss.qualcomm.com \
--cc=virtualization@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.