All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.