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