From nobody Fri Feb 13 22:36:10 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 227CE13956D for ; Mon, 20 May 2024 19:14:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716232499; cv=none; b=uwlcbSjOJ+ipEJCEH9r7j1+Z+qaxiZgZkBve3tZEdwabO1waXlHGyTUvGCqtijAr0tFM92iM6w+QO3bb6BBh75SbeyqqD5C0/6e0YDuoZFjuqLGOJz5ifPEEB94Ar4yLd8SG3bjwk+uavcYsnykZJ0jplX38rljHVZoSBQM+lWQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716232499; c=relaxed/simple; bh=aKWSKFKGF6zwX7P7XN89k4m4AaRFffhHWHjbFPxtRpk=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=BlxeLt1+ATh6Ub07AB3msM8Z5r/aqyLNvM7jKZIaSL6zw4psH9PGRWFa+KFL2bqOMaISuYO0NuGvdl9Dj5LxkwIZyY88sKTqR1LvPMk1ncNDlRhtdRfak4dxRAG/oQcmKC3Gi/R4LMD5MAEmbjuRT8yTBdt6pws672hzv1Ey9/c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 361BEDA7; Mon, 20 May 2024 12:15:19 -0700 (PDT) Received: from e121345-lin.cambridge.arm.com (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 57CC43F641; Mon, 20 May 2024 12:14:54 -0700 (PDT) From: Robin Murphy To: joro@8bytes.org Cc: iommu@lists.linux.dev, will@kernel.org, linux-kernel@vger.kernel.org, Jon Hunter , Jerry Snitselaar Subject: [PATCH] iommu/dma: Fix domain init Date: Mon, 20 May 2024 20:14:44 +0100 Message-Id: <721fa6baebb0924aa40db0b8fb86bcb4538434af.1716232484.git.robin.murphy@arm.com> X-Mailer: git-send-email 2.39.2.101.g768bb238c484.dirty Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Despite carefully rewording the kerneldoc to describe the new direct interaction with dma_range_map, it seems I managed to confuse myself in removing the redundant force_aperture check and ended up making the code not do that at all. This led to dma_range_maps inadvertently being able to set iovad->start_pfn =3D 0, and all the nonsensical chaos which ensues from there. Restore the correct behaviour of constraining base_pfn to the domain aperture regardless of dma_range_map, and not trying to apply dma_range_map constraints to the basic IOVA domain since they will be properly handled with reserved regions later. Reported-by: Jon Hunter Reported-by: Jerry Snitselaar Fixes: e28a114243d1 ("iommu/dma: Make limit checks self-contained") Signed-off-by: Robin Murphy Reviewed-by: Jerry Snitselaar Tested-by: Jerry Snitselaar --- drivers/iommu/dma-iommu.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 89a53c2f2cf9..1ec89ca75c59 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -685,15 +685,15 @@ static int iommu_dma_init_domain(struct iommu_domain = *domain, struct device *dev =20 /* Check the domain allows at least some access to the device... */ if (map) { - dma_addr_t base =3D dma_range_map_min(map); - if (base > domain->geometry.aperture_end || + if (dma_range_map_min(map) > domain->geometry.aperture_end || dma_range_map_max(map) < domain->geometry.aperture_start) { pr_warn("specified DMA range outside IOMMU capability\n"); return -EFAULT; } - /* ...then finally give it a kicking to make sure it fits */ - base_pfn =3D max(base, domain->geometry.aperture_start) >> order; } + /* ...then finally give it a kicking to make sure it fits */ + base_pfn =3D max_t(unsigned long, base_pfn, + domain->geometry.aperture_start >> order); =20 /* start_pfn is always nonzero for an already-initialised domain */ mutex_lock(&cookie->mutex); --=20 2.39.2.101.g768bb238c484.dirty