On Tue, Jul 15, 2025 at 01:55:01PM +0800, Baolu Lu wrote:
Yes, the mm (struct mm of processes that are bound to devices) list is an unbounded list and can theoretically grow indefinitely. This results in an unpredictable critical region.
Every MM has a unique PASID so I don't see how you can avoid this.
@@ -654,6 +656,9 @@ struct iommu_ops {
int (*def_domain_type)(struct device *dev);
- void (*paging_cache_invalidate)(struct iommu_device *dev,
unsigned long start, unsigned long end);
How would you even implement this in a driver?
You either flush the whole iommu, in which case who needs a rage, or the driver has to iterate over the PASID list, in which case it doesn't really improve the situation.
If this is a concern I think the better answer is to do a defered free like the mm can sometimes do where we thread the page tables onto a linked list, flush the CPU cache and push it all into a work which will do the iommu flush before actually freeing the memory.
One of the KPTI options might be easier at that point..
Jason