Re: [RFC PATCH 13/15] iommufd: Persist iommu domains for live update

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Oct 02, 2025 at 05:30:53PM -0400, Pasha Tatashin wrote:
> > Maybe finish is too broad grained? What if each session had a finish?
> > All the objects in the session are cleaned up, invoke the session
> > finish and the memfd's in the session unfreeze?
> 
> All sessions have their own finish:
> https://lore.kernel.org/all/20250929010321.3462457-15-pasha.tatashin@soleen.com
> LIVEUPDATE_SESSION_SET_EVENT
> 
> Each session can go into a "finished" state independently. However, I
> am still thinking about whether a dependency graph is needed. I feel
> that if we require FDs to be added to a session in a specific order
> (i.e., dependencies must be added first), and every subsequent FD
> checks that all prerequisites are already in the session via the
> existing can_preserve() callback, we should be okay, as long as we
> finish() them in reverse order.

I don't think it is quite that simple, like "finishing" an
iommu_domain cannot reconnect it back to the memfd. The only way to
finish it in the current sketch is to delete it.

So if you have a notion that finish is disallowed and when it is
actually finished maybe the order doesn't matter?

eg it doesn't matter what order we unfreeze memfds in.

This sort of assumes that something outside luo is still ensuring that
no disallowed operations are happening to the objects. eg nobody is
trying to ftruncate a memfd.

But I don't quite know what other objects besides memfd are going to
have this special frozen state??

> There are two issues:
> 1. What do we do with LIVEUPDATE_SESSION_UNPRESERVE_FD ?
> We can simply remove this IOCTL all together. Stuff can be unpreserved
> by simply closing session FD.

This is for serialize error handling? It does make sense if some sub
component of a session fails to serialize you'd just give up and close
the whole session.

> 2. Remembering this order on the way back, and since we are using the
> token as an iterator, that is not going to work, unless the graph is
> also preserved. However, now that we have sessions and the token
> values are independent for each session, I am thinking we can go back
> to the model where the kernel issues tokens when FDs are preserved, as
> each session will always start from token=0. This way FD preservation
> order and token order will always match.

You could just encode a preservation order numer in a seperate field?

Jason