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

From: Pasha Tatashin
Date: Sun Jun 08 2025 - 09:50:03 EST


On Thu, Jun 5, 2025 at 12:04 PM Pratyush Yadav <pratyush@xxxxxxxxxx> 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@xxxxxxxxxx>
> > ---
> > 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.

> This conflicts with my suggestion to have freeze callbacks never fail,
> but now that I think of it, this is also important, so maybe we have to
> live with freeze that can fail.
>
> > + if (h->fs->freeze) {
> > + ret = h->fs->freeze(h->file, h->fs->arg,
> > + &h->private_data);
> > + if (ret < 0) {
> > + pr_err("Freeze callback failed for file token %#0llx handler '%s' [%d]\n",
> > + (u64)token, h->fs->compatible, ret);
> > + __luo_do_files_cancel_calls(h);
> > +
> > + return ret;
> > + }
> > + }
> > + }
> > +
> > + ret = luo_files_commit_data_to_fdt();
> > + if (ret)
> > + __luo_do_files_cancel_calls(NULL);
> > +
> > + return ret;
> > }
> >
> > /**
> > @@ -316,7 +402,20 @@ int luo_do_files_freeze_calls(void)
> > */
> > void luo_do_files_finish_calls(void)
> > {
> > + unsigned long token;
> > + struct luo_file *h;
> > +
> > luo_files_recreate_luo_files_xa_in();
> > + xa_for_each(&luo_files_xa_in, token, h) {
> > + mutex_lock(&h->mutex);
> > + if (h->state == LIVEUPDATE_STATE_UPDATED && h->fs->finish) {
> > + h->fs->finish(h->file, h->fs->arg,
> > + h->private_data,
> > + h->reclaimed);
> > + h->state = LIVEUPDATE_STATE_NORMAL;
> > + }
> > + mutex_unlock(&h->mutex);
> > + }
>
> We can also clean up luo_files_xa_in at this point, right?

Yes, we can.

Thank you,
Pasha

>
> > }
> >
> > /**
> > @@ -330,6 +429,8 @@ void luo_do_files_finish_calls(void)
> > */
> > void luo_do_files_cancel_calls(void)
> > {
> > + __luo_do_files_cancel_calls(NULL);
> > + luo_files_commit_data_to_fdt();
> > }
> >
> > /**
>
> --
> Regards,
> Pratyush Yadav