On 09/08/16 16:36, Joerg Roedel wrote: > On Tue, Aug 09, 2016 at 04:23:18PM +0100, Robin Murphy wrote: >> Where a device driver has set a 64-bit DMA mask to indicate the absence >> of addressing limitations, we still need to ensure that we don't >> allocate IOVAs beyond the actual input size of the IOMMU. The reported >> aperture is the most reliable way we have of inferring that input >> address size, so use that to enforce a hard upper limit. >> >> Signed-off-by: Robin Murphy <robin.mur...@arm.com> > > Also missing 'Fixes:' line. > >> --- >> >> This is the only other thing I currently have which could perhaps be >> considered a fix; otherwise I'll pull it into the PCI/SMMU series. >> >> drivers/iommu/dma-iommu.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c >> index 7d991c81c4fa..092d781f5f35 100644 >> --- a/drivers/iommu/dma-iommu.c >> +++ b/drivers/iommu/dma-iommu.c >> @@ -158,6 +158,8 @@ static struct iova *__alloc_iova(struct iova_domain >> *iovad, size_t size, >> unsigned long shift = iova_shift(iovad); >> unsigned long length = iova_align(iovad, size) >> shift; >> >> + if (domain->geometry.force_aperture) >> + dma_limit &= domain->geometry.aperture_end; > > This might work, but is misleading as limits and aperture_end are > neither a mask nor a bitfield. It is more descriptive to use min() > here: > > dma_limit = min(dma_limit, omain->geometry.aperture_end); >
Well, dma_limit is always a DMA mask, but I suppose you're right that an IOMMU driver could in theory set a wacky non-power-of-two aperture if it really wanted to. I'll respin... Thanks, Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
