BMC/Intel-BMC/linux.git/drivers/iommu, branch dev-4.3

iommu/io-pgtable-arm: Ensure we free the final level on teardown

2016-02-19T22:28:34+00:00

commit 12c2ab09571e8aae3a87da2a4a452632a5fac1e5 upstream. When tearing down page tables, we return early for the final level since we know that we won't have any table pointers to follow. Unfortunately, this also means that we forget to free the final level, so we end up leaking memory. Fix the issue by always freeing the current level, but just don't bother to iterate over the ptes if we're at the final level. Reported-by: Zhang Bo Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints

2016-01-31T19:25:54+00:00

commit d14053b3c714178525f22660e6aaf41263d00056 upstream. The VT-d specification says that "Software must enable ATS on endpoint devices behind a Root Port only if the Root Port is reported as supporting ATS transactions." We walk up the tree to find a Root Port, but for integrated devices we don't find one — we get to the host bridge. In that case we *should* allow ATS. Currently we don't, which means that we are incorrectly failing to use ATS for the integrated graphics. Fix that. We should never break out of this loop "naturally" with bus==NULL, since we'll always find bridge==NULL in that case (and now return 1). So remove the check for (!bridge) after the loop, since it can never happen. If it did, it would be worthy of a BUG_ON(!bridge). But since it'll oops anyway in that case, that'll do just as well. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

iommu/arm-smmu: Fix error checking for ASID and VMID allocation

2016-01-31T19:25:54+00:00

commit c0733a2cf30c1e7923b6ad4f8df67941502923de upstream. The bitmap allocator returns an int, which is one of the standard negative values on failure. Rather than assigning this straight to a u16 (like we do for the ASID and VMID callers), which means that we won't detect failure correctly, use an int for the purposes of error checking. Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

Merge tag 'iommu-fixes-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2015-10-26T22:44:13+00:00

Pull iommu fixes from Joerg Roedel: "Two late fixes for the AMD IOMMU driver: - add an additional check to the io page-fault handler to avoid a BUG_ON being hit in handle_mm_fault() - fix a problem with devices writing to the system management area and were blocked by the IOMMU because the driver wrongly cleared out the DTE flags allowing that access" * tag 'iommu-fixes-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/amd: Don't clear DTE flags when modifying it iommu/amd: Fix BUG when faulting a PROT_NONE VMA

Merge tag 'for-linus-20151021' of git://git.infradead.org/intel-iommu

2015-10-21T21:32:48+00:00

Pull intel-iommu bugfix from David Woodhouse: "This contains a single fix, for when the IOMMU API is used to overlay an existing mapping comprised of 4KiB pages, with a mapping that can use superpages. For the *first* superpage in the new mapping, we were correctly¹ freeing the old bottom-level page table page and clearing the link to it, before installing the superpage. For subsequent superpages, however, we weren't. This causes a memory leak, and a warning about setting a PTE which is already set. ¹ Well, not *entirely* correctly. We just free the page table pages right there and then, which is wrong. In fact they should only be freed *after* the IOTLB is flushed so we know the hardware will no longer be looking at them.... and in fact I note that the IOTLB flush is completely missing from the intel_iommu_map() code path, although it needs to be there if it's permitted to overwrite existing mappings. Fixing those is somewhat more intrusive though, and will probably need to wait for 4.4 at this point" * tag 'for-linus-20151021' of git://git.infradead.org/intel-iommu: iommu/vt-d: fix range computation when making room for large pages

iommu/amd: Don't clear DTE flags when modifying it

2015-10-21T09:29:06+00:00

During device assignment/deassignment the flags in the DTE get lost, which might cause spurious faults, for example when the device tries to access the system management range. Fix this by not clearing the flags with the rest of the DTE. Reported-by: G. Richard Bellamy Tested-by: G. Richard Bellamy Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel

iommu/amd: Fix BUG when faulting a PROT_NONE VMA

2015-10-15T14:13:07+00:00

handle_mm_fault indirectly triggers a BUG in do_numa_page when given a VMA without read/write/execute access. Check this condition in do_fault. do_fault -> handle_mm_fault -> handle_pte_fault -> do_numa_page mm/memory.c 3147 static int do_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, .... 3159 /* A PROT_NONE fault should not end up here */ 3160 BUG_ON(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))); Signed-off-by: Jay Cornwall Cc: # v4.1+ Signed-off-by: Joerg Roedel

iommu/vt-d: fix range computation when making room for large pages

2015-10-13T19:32:50+00:00

In preparation for the installation of a large page, any small page tables that may still exist in the target IOV address range are removed. However, if a scatter/gather list entry is large enough to fit more than one large page, the address space for any subsequent large pages is not cleared of conflicting small page tables. This can cause legitimate mapping requests to fail with errors of the form below, potentially followed by a series of IOMMU faults: ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083) In this example, a 4MiB scatter/gather list entry resulted in the successful installation of a large page @ vPFN 0xfdc00, followed by a failed attempt to install another large page @ vPFN 0xfde00, due to the presence of a pointer to a small page table @ 0x7f83a4000. To address this problem, compute the number of large pages that fit into a given scatter/gather list entry, and use it to derive the last vPFN covered by the large page(s). Cc: stable@vger.kernel.org Signed-off-by: Christian Zander Signed-off-by: David Woodhouse

Merge tag 'iommu-fixes-v4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2015-10-13T17:09:59+00:00

Pull IOMMU fixes from Joerg Roedel: "A few fixes piled up: - Fix for a suspend/resume issue where PCI probing code overwrote dev->irq for the MSI irq of the AMD IOMMU. - Fix for a kernel crash when a 32 bit PCI device was assigned to a KVM guest. - Fix for a possible memory leak in the VT-d driver - A couple of fixes for the ARM-SMMU driver" * tag 'iommu-fixes-v4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/amd: Fix NULL pointer deref on device detach iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices iommu/vt-d: Fix memory leak in dmar_insert_one_dev_info() iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA iommu/arm-smmu: Ensure IAS is set correctly for AArch32-capable SMMUs iommu/io-pgtable-arm: Don't use dma_to_phys()

iommu/amd: Fix NULL pointer deref on device detach

2015-10-09T15:59:33+00:00

When a device group is detached from its domain, the iommu core code calls into the iommu driver to detach each device individually. Before this functionality went into the iommu core code, it was implemented in the drivers, also in the AMD IOMMU driver as the device alias handling code. This code is still present, as there might be aliases that don't exist as real PCI devices (and are therefore invisible to the iommu core code). Unfortunatly it might happen now, that a device is unbound multiple times from its domain, first by the alias handling code and then by the iommu core code (or vice verca). This ends up in the do_detach function which dereferences the dev_data->domain pointer. When the device is already detached, this pointer is NULL and we get a kernel oops. Removing the alias code completly is not an option, as that would also remove the code which handles invisible aliases. The code could be simplified, but this is too big of a change outside the merge window. For now, just check the dev_data->domain pointer in do_detach and bail out if it is NULL. Reported-by: Andreas Hartmann Signed-off-by: Joerg Roedel