Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Fix ATS state tracking via ats_prepared gate

[Pranjal Shrivastava <praan@google.com>]

On Wed, May 20, 2026 at 11:51:42AM -0300, Jason Gunthorpe wrote:
> On Wed, May 20, 2026 at 02:24:47PM +0000, Pranjal Shrivastava wrote:
> 
> > However, I'm thinking what's the right thing to do if pci_enable_ats() 
> > fails in attach_commit():
> > 
> > 1. Fail to attach but unmerging the invs_array entry is complicated.
> 
> Is it? We should be able to keep the the original invs and not free
> it, just put the pointer back?

Reverting the invs pointer itself is straightforward, but IIUC the 
current implementation of arm_smmu_install_new_domain_invs() is a
destructive update as it calls kfree_rcu() on the old list immediately
after the swap.

Although, I guess we could refactor the RCU lifecycle to defer the 
kfree_rcu until after pci_enable_ats() succeeds in the commit phase?

> 
> > 2. Move the pci_enable_ats() to attach_prepare()
> 
> IIRC ATS cannot be enabled until the invs are loaded with ATS
> invalidations, hence the issue.

Ahh, right.
> 
> So you'd put the new invs list, turn on ATS, if it fails restore the
> invs list back to what it was and RCU free the new one(s).

I guess we'll have to to do the following:

1. Defer kfree_rcu of the old invs until attach_commit succeeds.
2. Implement a roll-back (writing the old STE/CD back) on enable failiure

Thanks,
Praan