Re: [PATCH rc] iommu/arm-smmu-v3: Drain in-flight fault handlers

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Mar 24, 2026 at 02:35:14PM +0000, Will Deacon wrote:
> On Tue, Mar 24, 2026 at 11:17:16AM -0300, Jason Gunthorpe wrote:
> > On Tue, Mar 24, 2026 at 02:04:03PM +0000, Will Deacon wrote:
> > > Sorry, that was sloppy terminology on my part. I'm trying to reason about
> > > faults that are generated by accesses that were translated with the
> > > page-tables of the old domain being reported once we think we are using
> > > the new domain.
> > 
> > It doesn't matter.
> > 
> > If a concurrent fault is resolving on the old domain and it completes
> > after the STE is in the new domain the device will restart and if the
> > IOVA is still non-present it will refault. This is normal and fine.
> > 
> > If it is resolving on the new domain and the new domain has a present
> > PTE so the PRI is spurious then the fault handler should NOP it and
> > restart the device.
> 
> Hmm, I can see that working out if both domains expect faults, but if
> I'm switching to a domain without a handler 

iommu_report_device_fault() still handles the event and generates an
error ack.

> wouldn't I be better off draining the outstanding faults generated
> on the old domain first?  Otherwise, won't we see a bunch of noise
> from the eventq thread as it dumps unexpected events to the console?

Yes, it does look like since iommu_report_device_fault() handles it
but returns an error code we will get a print.

You'd need to double flush the the event queue. We always have to
flush after changing the group->domain since that is preventing a UAF

Then you'd have to flush before changing the group->domain to avoid
the prints if faulting is being disabled.

IDK, may not be worth worrying about or maybe we should just remove
the prints..

Jason