summaryrefslogtreecommitdiff
path: root/drivers/iommu/intel-iommu.c
diff options
context:
space:
mode:
authorRobin Murphy <robin.murphy@arm.com>2017-05-16 14:26:48 +0300
committerJoerg Roedel <jroedel@suse.de>2017-05-17 16:34:15 +0300
commit757c370f036e1f9f9a816cd481a13cdbcb346eb9 (patch)
tree486a0a42f1d0468a7e640c4e8517d5226d5a5306 /drivers/iommu/intel-iommu.c
parent2ea659a9ef488125eb46da6eb571de5eae5c43f6 (diff)
downloadlinux-757c370f036e1f9f9a816cd481a13cdbcb346eb9.tar.xz
iommu/iova: Sort out rbtree limit_pfn handling
When walking the rbtree, the fact that iovad->start_pfn and limit_pfn are both inclusive limits creates an ambiguity once limit_pfn reaches the bottom of the address space and they overlap. Commit 5016bdb796b3 ("iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range") fixed the worst side-effect of this, that of underflow wraparound leading to bogus allocations, but the remaining fallout is that any attempt to allocate start_pfn itself erroneously fails. The cleanest way to resolve the ambiguity is to simply make limit_pfn an exclusive limit when inside the guts of the rbtree. Since we're working with PFNs, representing one past the top of the address space is always possible without fear of overflow, and elsewhere it just makes life a little more straightforward. Reported-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
Diffstat (limited to 'drivers/iommu/intel-iommu.c')
0 files changed, 0 insertions, 0 deletions