linux-toradex.git/drivers/iommu/iova.c, branch v4.4.156

iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range

2018-03-22T08:23:24+00:00

[ Upstream commit 5016bdb796b3726eec043ca0ce3be981f712c756 ]

Normally, calling alloc_iova() using an iova_domain with insufficient
pfns remaining between start_pfn and dma_limit will fail and return a
NULL pointer. Unexpectedly, if such a "full" iova_domain contains an
iova with pfn_lo == 0, the alloc_iova() call will instead succeed and
return an iova containing invalid pfns.

This is caused by an underflow bug in __alloc_and_insert_iova_range()
that occurs after walking the "full" iova tree when the search ends
at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just
below that (-1). This (now huge) limit_pfn gives the impression that a
vast amount of space is available between it and start_pfn and thus
a new iova is allocated with the invalid pfn_hi value, 0xFFF.... .

To rememdy this, a check is introduced to ensure that adjustments to
limit_pfn will not underflow.

This issue has been observed in the wild, and is easily reproduced with
the following sample code.

	struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
	struct iova *rsvd_iova, *good_iova, *bad_iova;
	unsigned long limit_pfn = 3;
	unsigned long start_pfn = 1;
	unsigned long va_size = 2;

	init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn);
	rsvd_iova = reserve_iova(iovad, 0, 0);
	good_iova = alloc_iova(iovad, va_size, limit_pfn, true);
	bad_iova = alloc_iova(iovad, va_size, limit_pfn, true);

Prior to the patch, this yielded:
	*rsvd_iova == {0, 0}   /* Expected */
	*good_iova == {2, 3}   /* Expected */
	*bad_iova  == {-2, -1} /* Oh no... */

After the patch, bad_iova is NULL as expected since inadequate
space remains between limit_pfn and start_pfn after allocating
good_iova.

Signed-off-by: Nate Watterson 
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iommu: Make the iova library a module

2015-07-28T14:48:01+00:00

The iova library has use outside the intel-iommu driver, thus make it a
module.

Signed-off-by: Sakari Ailus 
Signed-off-by: David Woodhouse

iommu: iova: Export symbols

2015-07-28T14:48:00+00:00

Use EXPORT_SYMBOL_GPL() to export the iova library symbols. The symbols
include:

	init_iova_domain();
	iova_cache_get();
	iova_cache_put();
	iova_cache_init();
	alloc_iova();
	find_iova();
	__free_iova();
	free_iova();
	put_iova_domain();
	reserve_iova();
	copy_reserved_iova();

Signed-off-by: Sakari Ailus 
Signed-off-by: David Woodhouse

iommu: iova: Move iova cache management to the iova library

2015-07-28T14:47:58+00:00

This is necessary to separate intel-iommu from the iova library.

Signed-off-by: Sakari Ailus 
Signed-off-by: David Woodhouse

iommu/iova: Avoid over-allocating when size-aligned

2015-07-28T14:47:56+00:00

Currently, allocating a size-aligned IOVA region quietly adjusts the
actual allocation size in the process, returning a rounded-up
power-of-two-sized allocation. This results in mismatched behaviour in
the IOMMU driver if the original size was not a power of two, where the
original size is mapped, but the rounded-up IOVA size is unmapped.

Whilst some IOMMUs will happily unmap already-unmapped pages, others
consider this an error, so fix it by computing the necessary alignment
padding without altering the actual allocation size. Also clean up by
making pad_size unsigned, since its callers always pass unsigned values
and negative padding makes little sense here anyway.

Signed-off-by: Robin Murphy 
Signed-off-by: David Woodhouse

iommu: Fix checkpatch warnings for Missing a blank line after declarations

2015-05-05T15:49:34+00:00

Fixed checkpatch warnings for missing blank line after
declaration of struct.

Signed-off-by: Robert Callicotte 
Signed-off-by: Joerg Roedel

iommu: Make IOVA domain page size explicit

2015-01-19T13:55:22+00:00

Systems may contain heterogeneous IOMMUs supporting differing minimum
page sizes, which may also not be common with the CPU page size.
Thus it is practical to have an explicit notion of IOVA granularity
to simplify handling of mapping and allocation constraints.

As an initial step, move the IOVA page granularity from an implicit
compile-time constant to a per-domain property so we can make use
of it in IOVA domain context at runtime. To keep the abstraction tidy,
extend the little API of inline iova_* helpers to parallel some of the
equivalent PAGE_* macros.

Signed-off-by: Robin Murphy 
Signed-off-by: Joerg Roedel

iommu: Make IOVA domain low limit flexible

2015-01-19T13:55:22+00:00

To share the IOVA allocator with other architectures, it needs to
accommodate more general aperture restrictions; move the lower limit
from a compile-time constant to a runtime domain property to allow
IOVA domains with different requirements to co-exist.

Also reword the slightly unclear description of alloc_iova since we're
touching it anyway.

Signed-off-by: Robin Murphy 
Signed-off-by: Joerg Roedel

iommu: Consolidate IOVA allocator code

2015-01-19T13:55:22+00:00

In order to share the IOVA allocator with other architectures, break
the unnecssary dependency on the Intel IOMMU driver and move the
remaining IOVA internals to iova.c

Signed-off-by: Robin Murphy 
Signed-off-by: Joerg Roedel

iommu/vt-d: Update IOMMU state when memory hotplug happens

2014-03-04T16:51:06+00:00

If static identity domain is created, IOMMU driver needs to update
si_domain page table when memory hotplug event happens. Otherwise
PCI device DMA operations can't access the hot-added memory regions.

Signed-off-by: Jiang Liu 
Signed-off-by: Joerg Roedel