Re: Qns: LUO: Should luo_core throw warning for preserved resource under unregistered handlers

Re: Qns: LUO: Should luo_core throw warning for preserved resource under unregistered handlers

[tarunsahu]

+ kexec list.

Tarun Sahu <tarunsahu@google.com> writes:

> Hi,
>
> I have a question. If a luo_handler is registered as part of the module
> And In new kernel, the module isn't loaded so the handler will also not
> be registered. And the resources/files preserved in older kernel will be
> leaked after luo_finish in new kernel. Right now, Luo core does not
> throw any warning. Should it throw a warning or prevent finish and let
> the user re-attempt the finish with force if they want.
>
> Guest_memfd preservation is such an example. It gets registered during
> kvm module load.
>
> I remember there was similar discussion raised by Samiullah for
> resources not retrieved but their handler was registered.
>
> ~Tarun

Re: Qns: LUO: Should luo_core throw warning for preserved resource under unregistered handlers

[Pratyush Yadav]

On Mon, Aug 10 2026, tarunsahu@google.com wrote:

> + kexec list.
>
> Tarun Sahu <tarunsahu@google.com> writes:
>
>> Hi,
>>
>> I have a question. If a luo_handler is registered as part of the module
>> And In new kernel, the module isn't loaded so the handler will also not
>> be registered. And the resources/files preserved in older kernel will be
>> leaked after luo_finish in new kernel. Right now, Luo core does not
>> throw any warning. Should it throw a warning or prevent finish and let
>> the user re-attempt the finish with force if they want.
>>
>> Guest_memfd preservation is such an example. It gets registered during
>> kvm module load.

I went and took a look at the code. When you first open /dev/liveupdate
luo_session_deserialize() is called. It calls deserializes each session.
As part of that deserialization, for each session luo_file_deserialize()
walks the list of preserved files and calls luo_file_deserialize_one()
to try and find a handler for that file.

If no handler is found, it prints an error and returns -ENOENT.
Eventually that error bubbles up to luo_session_deserialize() and causes
the open of /dev/liveupdate to fail. It also saves the error code and
all future opens fail too.

So in this case, the end result will be that _all_ files will be leaked
and /dev/liveupdate will fail to open. You never even get to finish. The
system daemon will probably have to trigger a cold reboot, treating all
VMs as dead.

The kernel at least keeps itself safe here and won't crash or anything
like that. It prints an error too. And I think it isn't unreasonable to
expect userspace to load all modules needed by live update before
opening /dev/liveupdate. So I don't think the current state is all too
bad.

That said, perhaps we can improve this behaviour. For one, if one module
is missing and that module is only used by one session, that will still
DoS all other sessions. I guess we can move the call to
luo_session_deserialize_one() to luo_session_retrieve()? This way, you
only block the retrieval of sessions with missing handlers. All others
work fine. Perhaps we can also make the error on missing handler
retry-able. If we see a missing handler on session retrieve, we let
userspace retry, giving it a chance to load all its modules.

I don't know how useful the retrying will be in practice, but the
deserialize on retrieve can be fairly useful I think.

>>
>> I remember there was similar discussion raised by Samiullah for
>> resources not retrieved but their handler was registered.

For this one I think LUO should automatically retrieve the files and
then finish them. I don't think there is any point in leaking those when
we know how to clean up.

-- 
Regards,
Pratyush Yadav