Re: [PATCH v2 03/30] iommu/io-pgtable-arm-v7s: introduce iova_to_phys_length in io_pgtable_ops

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using PHYS_ADDR_MAX as an error sentinel breaks valid translations to high physical memory on 32-bit systems.
--

commit 8d5316c44c1d3b102a4d8d7b0ce51537aca692ab
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>

iommu/io-pgtable-arm-v7s: introduce iova_to_phys_length in io_pgtable_ops

Implement iova_to_phys_length in ARM v7s backend: returns block size
derived from level mask. The old iova_to_phys is kept as a thin wrapper.

> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
[ ... ]
> +static phys_addr_t arm_v7s_iova_to_phys(struct io_pgtable_ops *ops,
> +					unsigned long iova)
> +{
> +	phys_addr_t phys = arm_v7s_iova_to_phys_length(ops, iova, NULL);
> +
> +	return (phys == PHYS_ADDR_MAX) ? 0 : phys;

[Severity: High]
Does this condition inadvertently catch valid translations on 32-bit systems?

If CONFIG_PHYS_ADDR_T_64BIT is disabled, phys_addr_t is 32-bit, making
PHYS_ADDR_MAX exactly 0xFFFFFFFF. Since 0xFFFFFFFF can be a valid physical
address (e.g., in MMIO space), a valid IOVA mapping that resolves to
0xFFFFFFFF would perfectly match the error sentinel and incorrectly return 0.

> +}
> +
> +static phys_addr_t arm_v7s_iova_to_phys_length(struct io_pgtable_ops *ops,
> +						unsigned long iova,
> +						size_t *mapped_length)
>  {
[ ... ]
>  	if (!ARM_V7S_PTE_IS_VALID(pte))
> -		return 0;
> +		return PHYS_ADDR_MAX;

[Severity: High]
Could this similarly cause direct callers of iova_to_phys_length() to
misinterpret a legitimate translation to 0xFFFFFFFF as a failure?

Since 0xFFFFFFFF is a valid physical address, using it as an error sentinel
might make it impossible to correctly translate IOVAs pointing to the top byte
of memory on 32-bit systems.

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