When initial placement of the new entry crosses the boundary,

allocator tries to move the entry up, after the boundary.  The new
location may still fail to satisfy boundary requirement, for instance,
if the boundary is set to page size, and allocation is of multiple
pages.

Recheck that boundary is not crossed after the move.  If it is
crossed, give up on allocating the whole entry and split it.

Reported by:	Michael Fuckner <michael@fuckner.net>, running nvme(4)
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week

diff --git a/sys/x86/iommu/intel_gas.c b/sys/x86/iommu/intel_gas.c
index 5ccf34ba68eacb08a7fd555d70e4cdda565f2188..2049744083051537173c62402ba6c18d97e56898 100644 (file)
--- a/sys/x86/iommu/intel_gas.c
+++ b/sys/x86/iommu/intel_gas.c
@@ -327,13 +327,15 @@ dmar_gas_match_one(struct dmar_gas_match_args *a, struct dmar_map_entry *prev,
        start = roundup2(bs, a->common->alignment);
        /* DMAR_PAGE_SIZE to create gap after new entry. */
        if (start + a->size + DMAR_PAGE_SIZE <= prev->end + prev->free_after &&
-           start + a->size <= end) {
+           start + a->size <= end && dmar_test_boundary(start, a->size,
+           a->common->boundary)) {
                a->entry->start = start;
                return (true);
        }
 
        /*
-        * Not enough space to align at boundary, but allowed to split.
+        * Not enough space to align at the requested boundary, or
+        * boundary is smaller than the size, but allowed to split.
         * We already checked that start + size does not overlap end.
         *
         * XXXKIB. It is possible that bs is exactly at the start of