Re: [PATCH v3 30/32] iommu/io-pgtable-arm-v7s: remove deprecated iova_to_phys wrapper

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm_smmu_iova_to_phys_hard() returns 0 on translation faults instead of PHYS_ADDR_MAX, which is misinterpreted as a valid physical address.
--

commit 559ce0b481cdf56b10eb2174df50ab821772a973
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>

iommu/io-pgtable-arm-v7s: remove deprecated iova_to_phys wrapper

Remove the iova_to_phys wrapper function and .iova_to_phys assignment
from ARM v7s io-pgtable, as all callers now use iova_to_phys_length.

> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index 62198e31a3937..da065747e37c7 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
[ ... ]
> @@ -641,18 +641,6 @@ static size_t arm_v7s_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova
>  	return unmapped;
>  }
>  
> -static phys_addr_t arm_v7s_iova_to_phys_length(struct io_pgtable_ops *ops,
> -						unsigned long iova,
> -						size_t *mapped_length);
> -
> -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]
While this patch removes the wrapper that converted the error sentinel from
PHYS_ADDR_MAX to 0, was arm_smmu_iova_to_phys_hard() in arm-smmu.c missed
during the transition?

In drivers/iommu/arm/arm-smmu/arm-smmu.c:

    phys_addr_t addr = 0;

    ret = arm_smmu_rpm_get(smmu);
    if (ret < 0)
        return 0;
    ...
    if (phys & ARM_SMMU_CB_PAR_F) {
        dev_err(dev, "translation fault!\n");
        dev_err(dev, "PAR = 0x%llx\n", phys);
        goto out;
    }

    addr = (phys & GENMASK_ULL(39, 12)) | (iova & 0xfff);
out:
    arm_smmu_rpm_put(smmu);

    return addr;

Since arm_smmu_iova_to_phys_length() directly returns the result of this hardware
translation path, it will still return 0 on RPM failures or translation faults.

Will this cause callers like iommufd and vfio, which now check for PHYS_ADDR_MAX,
to mistake the error for a valid physical address at 0?

Also, since mapped_length is not set in this path, will it break the caller's
mapping size calculations?

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