Re: [PATCH 1/1] liveupdate: luo_file: Add internal APIs for file preservation

[Samiullah Khawaja]

On Fri, Jul 17, 2026 at 07:24:17PM +0200, Pratyush Yadav wrote:
> On Mon, Jul 06 2026, Samiullah Khawaja wrote:
>
> > Hi,
> >
> > Sorry I was out of office, so couldn't contribute to this discussion
> > early.
> >
> > On Mon, Jun 29, 2026 at 06:50:09PM +0200, Pratyush Yadav wrote:
> > > On Mon, Jun 29 2026, Pratyush Yadav wrote:
> > >
> > > > On Mon, Jun 29 2026, Pasha Tatashin wrote:
> > > >
> > > > > On 06-26 13:57, Pratyush Yadav wrote:
> > > > > > Hi Sami,

[snip]

> > > > > Actually, preservation can also be performed in an order-independent manner.
> > > > > While a handler can call liveupdate_get_token_outgoing() during .preserve(),
> > > > > it can also defer this query until the .freeze() callback. Because .freeze()
> > > > > is invoked after all files in the session have completed their .preserve() phase,
> > > > > all dependency tokens are guaranteed to be available, completely eliminating any
> > > > > topological ordering requirements during the initial preservation calls. It is
> > > > > up to individual file handler implementations to decide whether they wish to
> > > > > enforce ordering at .preserve() time or defer it to .freeze().

Quoting this text from pasha below.
> > > > That is the worst of both worlds. I get your point that LUO doesn't want
> > > > to enforce dependency ordering. My arguments against that are somewhat
> > > > subjective so I can live with this.
> >
> > Pasha replied with some interesting points already, but I want to add
> > some clarification here.
> >
> > During preservation, enforcing order gives the following functionality:
> >
> > - The token of the dependency (can be retrieved during freeze as you
> >   suggested).
> > - The dependency is preserved and that means it has bound with the LUO
> >   session lifecycle. This guarantees that it is not going to go away
> >   until the session is closed.
> > - Once preserved, the dependency is in some kind of "immutable" state.
> >   This might not be required by all dependent FDs, but it is critical
> >   for some.
> >
> > These ordering requirements should be clearly documented by the
> > associated filehandler so the VMM knows how to do the preservation of a
> > specific FD properly. This is actually similar to the memfd seal rule
> > that iommufd preservation will enforce.
> > > > But then you can't let file handlers enforce it as they wish. The
> > > > dependency ordering is uAPI because it directly affects how VMMs
> > > > preserve files. If the VMM has to keep track of dependencies for some
> > > > file types and doesn't have to do so for others, that is a terrible and
> > > > inconsistent API.
> >
> > But as you have already pointed out that the VFIO/IOMMUFD circular
> > dependency is resolved, I am okay with enforcing dependency ordering
> > during restore as well. However, establishing an ordered
> > preserve/restore mandate in LUO at this point will force all future file
> > handlers into complicated and buggy design choices if they have circular
> > dependency or different lifecycle requirements.
>
> Not really. You can always _relax_ the ordering requirements if a need
> does come up. Because all the programs following the ordering will still
> continue to work. The other way round won't work though.

Yes, this is a fair point.
> > > > Ideally, LUO should handle the dependencies on its own. preserve() can
> > > > give LUO a list of files the preserved file depends on, and LUO makes
> > > > sure all the dependencies are present in the session at freeze. We would
> >
> > This again assumes the lifecycle of various FDs and that dependencies
> > can be resolved during freeze(). Some file handlers do want order of
> > preservation, and this scheme only guarantees preservation dependency
> > without order, introducing hacky dependency state management until
> > freeze().
> > > > also need a way of getting the dependent files back from LUO on
> > > > retrieve(). That would make sure the dependencies are properly enforced
> > > > both on freeze and finish, and the enforcement isn't left up to the file
> > > > handlers.
> > > >
> > > > Unfortunately all that sounds fairly complicated so I am not sure if we
> > > > want to do that just yet, although I would like to hear your thoughts on
> > > > this.
> > >
> > > We had discussion about this in the live update bi-weekly today. The
> > > conclusion we arrived at is to keep the current functionality. That is,
> > > we don't enforce preservation dependency.
> > >
> > > But that also means file handlers can't try to get their dependent file
> > > in their preserve() callback, since that would implicitly enforce
> > > ordering. They always _have_ to do it from their freeze() callback.
> >
> > This has problems at multiple levels:
> >
> > - This indirectly sets up a precedent in uAPI that the VMM is allowed to
> >   preserve the FDs in any order and the file handler will be able to
> >   handle this.
> > - This will be very tricky and will force filehandler to have
> >   complicated/hacky state management to handle dependency. Specifically
> >   I do need iommufd to be preserved before preserving the VFIO cdev that
> >   has an iommufd dependency. Not sure, but I think this will also be
> >   tricky when we start preservation of VFs and SRIOV PFs.
> >
> > I don't think LUO should enforce an arbitrary rule like this unless we
> > have a strong reasoning behind it.
>
> It looks like you, me, and Pasha are saying slightly different things.
> We all first need to take a step back and lay out our proposals clearly.
> I'll write my points down, and I'll try to reproduce what I understood
> from discussions with you and Pasha.

Thanks for laying down your points clearly. I'll reply to point 1 and 3
together as those are entangled I think.

> I think we should focus discussions around the below 3 high level topics,
> and we can figure out the implementation details later.
>
> 1. Do dependent files need to be preserved before their main files?
> 2. Do we apply the same rules to preserve() and retrieve()?
> 3. Do the rules apply to all file handler or can file handlers choose
>   their rules?
>
> Here's my take for 1: Say A depends on B. I think it would be a good
> idea for LUO to enforce that B gets preserved before A. You already
> mentioned a few reasons for why. Similarly, LUO should also enforce that
> B gets restored before A. We can figure out where the actual enforcement
> happens, but that would be the principle of the LUO API.
>
> Pasha suggests the opposite. In my discussions, and this email thread,
> he doesn't want to enforce _any_ ordering. So you can preserve A and B
> at any time and you check at freeze() that everything is present. Now I

Just to correct/clarify, quoting Pasha from his earlier email in this
thread:

"It is up to individual file handler implementations to decide whether
they wish to enforce ordering at .preserve() time or defer it to
.freeze()."

Basically, a FH can choose to enforce ordering during preservation or
not enforce any ordering and check it during freeze(). I agree with
Pasha on this point, as it gives FHs the flexibility they need.

However, I see the value in maintaining consistency and simplicity for
the VMMs, we can enforce that dependencies are preserved in order as a
principle of the LUO API. I am ok with this. It might become tricky for
any future circular dependencies down the road, but we can relax this if
they come up, as you suggested above.

> see the value in this idea. It removes the need of tracking ordering
> from VMMs. But I think it is also somewhat dangerous, because what
> happens when freeze() fails? VMMs need to recover and restart the VMs or
> retry live update. I don't know if they would be able to do so. This
> path will likely be less tested.
>
> But still, I can live with that. At least for memfd, guest_memfd, etc.
> this shouldn't be very problematic. I am not sure about iommufd.
>
> So in conclusion, I would prefer to have ordering, but I can live with
> no ordering as well.

As elaborated in my previous email, I disagree with enforcing a
no-ordering policy.

> For 2, I think we should apply the same rules on both sides. Mainly for
> consistency. The VMMs should follow the right order for preservation and
> restoration. Now again, I am fine with both enforcing the ordering or
> not enforcing it, but I really think the rules should be consistent
> across both sides.
>
> From my reading, I think Pasha does as well, but from talking with you,
> IIUC you think retrieve is a fundamentally different operation and it
> should not enforce any ordering.
>
> I do see your point but I still think there is value in keeping things
> symmetric. Unfortunately this is fairly subjective, so I don't have much
> better arguments.

I agree with you on this. For consistency and simplicity, we can apply
the same rules on preserve/retrieve both.

> For 3, I _strongly_ think it should be a LUO wide policy. Leaving this
> up to file handlers will become messy over time because each would come
> up with its own rules and for VMMs there would be no consistency in how
> they should use LUO.
>
> I hope this helps focus our discussion to the major points. And again,
> we can figure out the implementation details as we go along, so I didn't
> reply to some of the points you raised in this email, to not distract
> too much.
>
> [...]
>
> --
> Regards,
> Pratyush Yadav

Also I think with the next revision of this series, if Pasha also agrees
with this, I will add documentation about FD dependency in general.

Thanks,
Sami