iommu: TLB sync timeouts and page table freeing on unmap

iommu: TLB sync timeouts and page table freeing on unmap

[Yuho Choi]

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

Re: iommu: TLB sync timeouts and page table freeing on unmap

[Robin Murphy]

On 22/10/2026 6:54 pm, Yuho Choi wrote:
> 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,

Yes. If the IOMMU is sufficiently wedged that it's not responding to 
invalidation, there's every chance it's also not processing client 
transactions either. Logging these warnings mainly serves to help 
contextualise related symptoms of the same underlying condition, like a 
client device also reporting errors, or a subsequent register access 
deadlocking entirely.

I can at least speak for arm-smmu-v3 to say that having the timeout 
warnings there has proven useful multiple times in pinpointing hardware 
issues when bringing up platforms on FPGA, but not things that Linux 
itself would ever have to attempt to "handle", or that would ever occur 
on final production hardware.

Thanks,
Robin.

> 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

Re: iommu: TLB sync timeouts and page table freeing on unmap

[Yuho Choi]

On Fri, 23 Oct 2026 at 11:47, Robin Murphy <robin.murphy@arm.com> wrote:
>
> Yes. If the IOMMU is sufficiently wedged that it's not responding to
> invalidation, there's every chance it's also not processing client
> transactions either. Logging these warnings mainly serves to help
> contextualise related symptoms of the same underlying condition, like a
> client device also reporting errors, or a subsequent register access
> deadlocking entirely.
>
> I can at least speak for arm-smmu-v3 to say that having the timeout
> warnings there has proven useful multiple times in pinpointing hardware
> issues when bringing up platforms on FPGA, but not things that Linux
> itself would ever have to attempt to "handle", or that would ever occur
> on final production hardware.

That makes sense, thanks for explaining. I'll leave these drivers as
they are.

Thanks,
Yuho