Hi Nathan, I may have just spotted something in these logs... On Fri, Jul 02, 2021 at 10:55:17PM -0700, Nathan Chancellor wrote: > [ 2.340956] pci 0000:0c:00.1: Adding to iommu group 4 > [ 2.340996] pci 0000:0c:00.2: Adding to iommu group 4 > [ 2.341038] pci 0000:0c:00.3: Adding to iommu group 4 > [ 2.341078] pci 0000:0c:00.4: Adding to iommu group 4 > [ 2.341122] pci 0000:0c:00.6: Adding to iommu group 4 > [ 2.341163] pci 0000:0d:00.0: Adding to iommu group 4 > [ 2.341203] pci 0000:0d:00.1: Adding to iommu group 4 > [ 2.361821] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 > [ 2.361839] pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade): > [ 2.361846] PPR X2APIC NX GT IA GA PC GA_vAPIC > [ 2.361861] AMD-Vi: Interrupt remapping enabled > [ 2.361865] AMD-Vi: Virtual APIC enabled > [ 2.361870] AMD-Vi: X2APIC enabled > [ 2.362272] AMD-Vi: Lazy IO/TLB flushing enabled So at this point, the AMD IOMMU driver does: swiotlb = (iommu_default_passthrough() || sme_me_mask) ? 1 : 0; where 'swiotlb' is a global variable indicating whether or not swiotlb is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which will call swiotlb_exit() if 'swiotlb' is false. Now, that used to work fine, because swiotlb_exit() clears 'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I think that all the devices which have successfully probed beforehand will have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem' field. Will
