Re: [RFC v2 09/16] luo: luo_files: implement file systems callbacks

[Pratyush Yadav <pratyush@kernel.org>]

On Mon, Jun 16 2025, Pasha Tatashin wrote:

> On Mon, Jun 16, 2025 at 6:43 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> On Fri, Jun 13 2025, Pasha Tatashin wrote:
>>
>> > On Fri, Jun 13, 2025 at 11:18 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>> >>
>> >> On Sun, Jun 08 2025, Pasha Tatashin wrote:
>> >>
>> >> > On Thu, Jun 5, 2025 at 12:04 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>> >> >>
>> >> >> On Thu, May 15 2025, Pasha Tatashin wrote:
>> >> >>
>> >> >> > Implements the core logic within luo_files.c to invoke the prepare,
>> >> >> > reboot, finish, and cancel callbacks for preserved file instances,
>> >> >> > replacing the previous stub implementations. It also handles
>> >> >> > the persistence and retrieval of the u64 data payload associated with
>> >> >> > each file via the LUO FDT.
>> >> >> >
>> >> >> > This completes the core mechanism enabling registered filesystem
>> >> >> > handlers to actively manage file state across the live update
>> >> >> > transition using the LUO framework.
>> >> >> >
>> >> >> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
>> >> >> > ---
>> >> >> >  drivers/misc/liveupdate/luo_files.c | 105 +++++++++++++++++++++++++++-
>> >> >> >  1 file changed, 103 insertions(+), 2 deletions(-)
>> >> >> >
>> >> >> [...]
>> >> >> > @@ -305,7 +369,29 @@ int luo_do_files_prepare_calls(void)
>> >> >> >   */
>> >> >> >  int luo_do_files_freeze_calls(void)
>> >> >> >  {
>> >> >> > -     return 0;
>> >> >> > +     unsigned long token;
>> >> >> > +     struct luo_file *h;
>> >> >> > +     int ret;
>> >> >> > +
>> >> >> > +     xa_for_each(&luo_files_xa_out, token, h) {
>> >> >>
>> >> >> Should we also ensure at this point that there are no open handles to
>> >> >> this file? How else would a file system ensure the file is in quiescent
>> >> >> state to do its final serialization?
>> >> >
>> >> > Do you mean check refcnt here? If so, this is a good idea, but first
>> >> > we need to implement the lifecycle of liveupdate agent correctectly,
>> >> > where owner of FD must survive through entering into reboot() with
>> >> > /dev/liveupdate still open.
>> >>
>> >> Yes, by this point we should ensure refcnt == 1. IIUC you plan to
>> >> implement the lifecycle change in the next revision, so this can be
>> >> added there as well I suppose.
>> >
>> > Yes, I am working on that. Current, WIP patch looks like this:
>> > https://github.com/soleen/linux/commit/fecf912d8b70acd23d24185a8c0504764e43a279
>> >
>> > However, I am not sure about refcnt == 1 at freeze() time. We can have
>> > programs, that never terminated while we were still in userspace (i.e.
>> > kexec -e -> reboot() -> freeze()), in that case refcnt can be anything
>> > at the time of freeze, no?
>>
>> Do you mean the agent that controls the liveupdate session? Then in that
> Yes
>> case the agent can keep running with the /dev/liveupdate FD open, but it
>> must close all of the FDs preserved via LUO before doing kexec -e.
>
> Right, but in this case the agent would have to basically kill all the

Or the participating processes can be cooperative and simply exit
cleanly, or at least close the FDs before triggering the kexec. The
whole live update process needs a lot of parts to cooperate anyway.

> processes the regestred FDs through it prior to 'kexec -e', I am not
> sure it is its job. However, we can add some pr_warn_once() when rfcnt
> != 1, I think this is a minor change. Lets do that once we have a more
> developed userspace setup. We need to start working on liveupdated

Sure, makes sense.

> that would through some sort of RPCs calls store and restore FDs.

I have been playing around with some ideas on how to do this. Will try
some things out and see if I can come up with a PoC soon.

-- 
Regards,
Pratyush Yadav