iommu: TLB sync timeouts and page table freeing on unmap

[Yuho Choi <oss.patchbox@gmail.com>]

Hi,

While looking at how IOMMU drivers handle TLB invalidation timeouts, I
noticed that several of them only log the timeout and carry on. For
example, ipmmu_tlb_sync() in drivers/iommu/ipmmu-vmsa.c (v7.3):

	if (read_poll_timeout_atomic(ipmmu_ctx_read_root, val,
				     !(val & IMCTR_FLUSH), 1, TLB_LOOP_TIMEOUT,
				     false, domain, IMCTR))
		dev_err_ratelimited(domain->mmu->dev,
			"TLB sync timed out -- MMU may be deadlocked\n");

and qcom_iommu_tlb_sync() in drivers/iommu/arm/arm-smmu/qcom_iommu.c
does the same. On unmap, __arm_lpae_unmap() in
drivers/iommu/io-pgtable-arm.c frees a page table right after the walk
flush:

	io_pgtable_tlb_flush_walk(iop, iova + i * size, size,
				  ARM_LPAE_GRANULE(data));
	__arm_lpae_free_pgtable(data, lvl + 1, iopte_deref(pte, data));

and the IOMMU core and its callers release the data pages after
->iotlb_sync(). Both callbacks return void, so a driver cannot stop
that when the invalidation did not complete.

Is a TLB sync timeout considered fatal enough that this does not
matter, or would you take changes in this area? For example, a driver
could record the failure and fail later map requests, as [1], or 
these callbacks could be allowed to return an error.

This came up during static analysis for research that is not yet
published; I have not seen such a timeout on hardware. I'm happy to
send patches if one of these directions is acceptable.

[1] https://lore.kernel.org/r/e2b13e82-f762-4fb0-83cb-d4bef57be427@linux.dev

Thanks,
Yuho