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

[Samiullah Khawaja <skhawaja@google.com>]

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