linux-kernel - Re: next-20250702 WARNING iommu io-pgtable-arm.c at arm_lpae_map_pages qcom_iommu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250709002521.GB1599700@nvidia.com>
Date: Tue, 8 Jul 2025 21:25:21 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Naresh Kamboju <naresh.kamboju@...aro.org>
Cc: open list <linux-kernel@...r.kernel.org>, iommu@...ts.linux.dev,
	lkft-triage@...ts.linaro.org,
	Linux Regressions <regressions@...ts.linux.dev>,
	Nicolin Chen <nicolinc@...dia.com>,
	Jean-Philippe Brucker <jean-philippe@...aro.org>,
	Anders Roxell <anders.roxell@...aro.org>,
	Ben Copeland <benjamin.copeland@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: next-20250702 WARNING iommu io-pgtable-arm.c at
 arm_lpae_map_pages qcom_iommu_map

On Wed, Jul 09, 2025 at 02:26:20AM +0530, Naresh Kamboju wrote:
> Regression identified while booting the Dragonboard 410c (Qualcomm
> APQ8016 SBC) using the Linux next-20250702 kernel tag. During device
> initialization, the kernel triggers a WARNING in the arm_lpae_map_pages()
> function, which is part of the IOMMU subsystem. The call trace also involves
> qcom_iommu_map().
> 
> Test environments:
> - Dragonboard-410c
> 
> Regression Analysis:
> - New regression? Yes
> - Reproducibility? Yes
> 
> Boot regression: next-20250702 WARNING iommu io-pgtable-arm.c at
> arm_lpae_map_pages qcom_iommu_map
> 
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> 
> List of suspected patches with recent changes.
>  * https://lore.kernel.org/all/0-v2-68a2e1ba507c+1fb-iommu_rm_ops_pgsize_jgg@nvidia.com/

Can you test this fix please:

--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -229,7 +229,7 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
                goto out_unlock;
 
        pgtbl_cfg = (struct io_pgtable_cfg) {
-               .pgsize_bitmap  = domain->pgsize_bitmap,
+               .pgsize_bitmap  = SZ_4K | SZ_64K | SZ_1M | SZ_16M,
                .ias            = 32,
                .oas            = 40,
                .tlb            = &qcom_flush_ops,
@@ -246,6 +246,8 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
                goto out_clear_iommu;
        }
 
+       /* Update the domain's page sizes to reflect the page table format */
+       domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap;
        domain->geometry.aperture_end = (1ULL << pgtbl_cfg.ias) - 1;
        domain->geometry.force_aperture = true;
 
@@ -335,7 +337,6 @@ static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
 
        mutex_init(&qcom_domain->init_mutex);
        spin_lock_init(&qcom_domain->pgtbl_lock);
-       qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M;
 
        return &qcom_domain->domain;
 }

Of all the drivers qcom is the only one that uses the 64 bit arm page
table, 4 & 64k sizes, and was using the ops global. The io_pgtable
code will remove one of the two depending on PAGE_SIZE which makes
things inconsistent and hits that warn.

Jason