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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux