Re: [PATCH v4 0/5] liveupdate: tighten handover cleanup and session lifetime

[Pasha Tatashin <pasha.tatashin@soleen.com>]

On Tue, Mar 24, 2026 at 5:29 PM Oskar Gerlicz Kowalczuk
<oskar@gerlicz.space> wrote:
>
> Hi Pasha,
>
> this v4 keeps the simpler direction from your mail: outgoing handover is
> still driven by a boolean rebooting gate, refcount pinning of outgoing
> sessions during serialization, and session->mutex as the serialization
> point for in-flight mutations. There is no return to the earlier closing
> counter or a larger session state machine.
>
> The main changes in this respin are:
>
> - reshape the series into five commits, each building and standing on its
>   own
> - keep incoming session origin immutable and use retrieved only as the
>   checked-out bit
> - make FINISH and implicit close consume incoming sessions without
>   reopening races through retrieve-by-name
> - route deserialize failures through explicit rollback paths for
>   sessions, files, and serialized memfd state
> - validate KHO-preserved extents before walking serialized metadata
> - harden incoming FLB lifetime and remaining teardown paths
>
> Patches 1-4 keep the core session, kexec, deserialize and validation work
> separate. Patch 5 carries the remaining FLB and teardown fixes needed to
> match the final tree.
>
> Oskar Gerlicz Kowalczuk (5):
>   liveupdate: block outgoing session updates during reboot
>   kexec: abort liveupdate handover on kernel_kexec() unwind
>   liveupdate: fail session restore on file deserialization errors
>   liveupdate: validate handover metadata before using it
>   liveupdate: harden FLB lifetime and remaining teardown paths
>
>  include/linux/kexec_handover.h     |  13 +
>  include/linux/liveupdate.h         |  17 +-
>  kernel/kexec_core.c                |   4 +
>  kernel/liveupdate/kexec_handover.c |  22 ++
>  kernel/liveupdate/luo_core.c       |  16 +-
>  kernel/liveupdate/luo_file.c       | 237 ++++++++++++--
>  kernel/liveupdate/luo_flb.c        | 116 +++++--
>  kernel/liveupdate/luo_internal.h   |  14 +-
>  kernel/liveupdate/luo_session.c    | 500 ++++++++++++++++++++++++-----
>  lib/tests/liveupdate.c             |   2 +
>  mm/memfd_luo.c                     | 160 +++++++--
>  11 files changed, 934 insertions(+), 167 deletions(-)

Hi Oskar,

This is a NAK.

This patch series is still significantly over-engineering solutions to
straightforward problems, and the patches read as if they were
mechanically generated rather than thoughtfully designed. The sheer
volume of changes (nearly 1,000 lines) is unnecessary for what we are
trying to achieve.

As I pointed out previously, we need to keep this simple. For example,
the problem of preventing a return to userspace after a successful
liveupdate_reboot() does not require inventing a new
liveupdate_reboot_abort() function. It just requires placing the call
where it's the last function allowed to return, with a simple
exception for context-preserved kexec jumps. That is a trivial change:

-       error = liveupdate_reboot();
-       if (error)
-               goto Unlock;
+       if (!kexec_image->preserve_context) {
+               error = liveupdate_reboot();
+               if (error)
+                       goto Unlock;
+       }

The same principle applies to the other issues. You are doing rewrites
when targeted fixes should be applied:
- Sessions mutating after entering the reboot() syscall?: This is a
14-line fix [1].
- Destroyed serialization race during liveupdate_reboot()? This is a
70-line fix [2].

I was hoping that v4 (BTW, why are we at v4 in just a week?) would
include the patches I already provided, along with similarly scoped,
minimal fixes for the deserialization path if needed. Instead, I am
seeing another over-complicated rewrite.

Looking at deserialization, I am seeing, you are deleting a comment
that explicitly explains our error-handling design:
-       /*
-        * Note on error handling:
-        *
-        * If deserialization fails (e.g., allocation failure or corrupt data),
-        * we intentionally skip cleanup of files that were already restored.
-        *
-        * A partial failure leaves the preserved state inconsistent.
-        * Implementing a safe "undo" to unwind complex dependencies (sessions,
-        * files, hardware state) is error-prone and provides little value, as
-        * the system is effectively in a broken state.
-        *
-        * We treat these resources as leaked. The expected recovery path is for
-        * userspace to detect the failure and trigger a reboot, which will
-        * reliably reset devices and reclaim memory.
-        */

You are adding a bunch of new functions to solve something we
intentionally chose not to solve. Attempting to cleanly unwind and
release incorrectly deserialized resources back to userspace is
dangerous. It risks security violations and, in the worst-case
scenario, customer data leaks. A failed deserialization means the
system is broken; we leak the resources (make them unavailable) and
rely on a reboot to reliably sanitize the state.

Please drop the over-engineered approaches. Use the patches provided,
keep the fixes minimal, and do not alter established security
boundaries like the deserialization error paths. Take your time to
manually self-review your work, do not rely on AI to do everything for
you.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/tatashin/linux.git/commit/?h=luo-reboot-sync/rfc/1&id=d47b76707c4f352c3f70384d3d6a818e2875439a
[2] https://git.kernel.org/pub/scm/linux/kernel/git/tatashin/linux.git/commit/?h=luo-reboot-sync/rfc/1&id=f27a6a9364cd0a19067734eeb24ea4d290b72139

Pasha

>
> --
> 2.53.0
>