mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-11-26 19:44:21 +08:00
iommu/dma: Fix domain init
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 = 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 <jonathanh@nvidia.com> Reported-by: Jerry Snitselaar <jsnitsel@redhat.com> Fixes: e28a114243d1 ("iommu/dma: Make limit checks self-contained") Signed-off-by: Robin Murphy <robin.murphy@arm.com>
This commit is contained in:
parent
50930e9d56
commit
15c80e749c
@ -686,15 +686,15 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev
|
||||
|
||||
/* Check the domain allows at least some access to the device... */
|
||||
if (map) {
|
||||
dma_addr_t base = 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 = max(base, domain->geometry.aperture_start) >> order;
|
||||
}
|
||||
/* ...then finally give it a kicking to make sure it fits */
|
||||
base_pfn = max_t(unsigned long, base_pfn,
|
||||
domain->geometry.aperture_start >> order);
|
||||
|
||||
/* start_pfn is always nonzero for an already-initialised domain */
|
||||
mutex_lock(&cookie->mutex);
|
||||
|
Loading…
Reference in New Issue
Block a user