On Mon, Sep 22, 2025 at 03:35:07PM +0530, Vasant Hegde wrote:
IMHO unless someone is actually hitting this I'd leave it and focus on merging iomupt which fully fixes this without adding any locks to the fast path.
Unfortunately yes. We had customer reporting this issue.
If a customer is actually hitting this then you definately need to solve the whole problem including the mmap race.
I guess adding a lock makes it easer to deal with, but this:
+ write_seqcount_begin(&pgtable->seqcount); pgtable->root = pte; pgtable->mode += 1; + write_seqcount_end(&pgtable->seqcount); + amd_iommu_update_and_flush_device_table(domain);
Is out of order.
The DTE has to be updated and caches flushed *before* writing the new information to the pgtable for other threads to observe.
You can look at what I did, but broadly you have to feed the new top as a function argument through to set_dte:
static void set_dte_entry(struct amd_iommu *iommu, - struct iommu_dev_data *dev_data) + struct iommu_dev_data *dev_data, + phys_addr_t top_paddr, unsigned int top_level) { u16 domid;
So the above can be ordered correctly.
You may also want to think about just disabling this optimization, always start with a 6 level table.
Jason