Re: [PATCH v2 13/30] iommu/fsl_pamu: implement iova_to_phys_length

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Assigning 64GB (1ULL << 36) to size_t *mapped_length causes a silent truncation to 0 on 32-bit platforms, leading to severe performance degradation and kernel lockups.
--

commit 0bcd395ee310c27e90762eec37163a95fe19bc3f
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>

iommu/fsl_pamu: implement iova_to_phys_length

This commit implements the iova_to_phys_length callback for the FSL PAMU
IOMMU driver. It configures the mapping to return the actual PTE mapping
size of the hardware window.

> diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
> index 9664ef9840d2c..643984ac6ae1c 100644
> --- a/drivers/iommu/fsl_pamu_domain.c
> +++ b/drivers/iommu/fsl_pamu_domain.c

[ ... ]

> -static phys_addr_t fsl_pamu_iova_to_phys(struct iommu_domain *domain,
> -					 dma_addr_t iova)
> +static phys_addr_t fsl_pamu_iova_to_phys_length(struct iommu_domain *domain,
> +						dma_addr_t iova,
> +						size_t *mapped_length)
>  {
> +	if (mapped_length)
> +		*mapped_length = 0;
> +
>  	if (iova < domain->geometry.aperture_start ||
>  	    iova > domain->geometry.aperture_end)
> -		return 0;
> +		return PHYS_ADDR_MAX;
> +
> +	/*
> +	 * PAMU configures exactly one Primary PAACE entry per LIODN with the
> +	 * Multi-Window (MW) bit cleared and ATM = PAACE_ATM_WINDOW_XLATE,
> +	 * WBAL/TWBAL = 0. That is, every LIODN is backed by a single hardware
> +	 * mapping window of fixed size (1ULL << 36, i.e. 64GB, see
> +	 * pamu_config_ppaace()) performing an identity translation. The driver
> +	 * does not split this window into SPAACE sub-windows, so the entire
> +	 * aperture is one PAACE "PTE" entry. Return that single entry's size
> +	 * as mapped_length, matching the iova_to_phys_length contract that
> +	 * mapped_length reports the full size of the mapping entry which
> +	 * covers iova (not the remaining bytes from iova to its end).
> +	 */
> +	if (mapped_length)
> +		*mapped_length = 1ULL << 36;

[Severity: High]
Will assigning 1ULL << 36 (64GB) to a size_t pointer cause a silent 
truncation to 0 on 32-bit platforms?

The FSL PAMU driver is used on 32-bit PowerPC architectures with 36-bit
physical addressing, where size_t is 32 bits wide. On these systems, 
attempting to store 0x1000000000 into a 32-bit integer truncates to exactly 0.

If mapped_length is reported as 0, IOMMU core callers (like iommufd page
iterators or vfio_unmap_unpin) can receive a 0 mapped length, which triggers
a WARN_ON(!pgsize) and falls back to advancing by PAGE_SIZE (typically 4KB).

Stepping through a 64GB window in 4KB increments requires over 16.7 million
iterations.

Could this massive loop cause extreme log spam and system lockups?

> +
>  	return iova;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602104637.1219810-1-guanghuifeng@linux.alibaba.com?part=13