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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <mafs0y0u6rx8y.fsf@kernel.org>
Date: Thu, 05 Jun 2025 18:03:57 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: pratyush@...nel.org,  jasonmiu@...gle.com,  graf@...zon.com,
  changyuanl@...gle.com,  rppt@...nel.org,  dmatlack@...gle.com,
  rientjes@...gle.com,  corbet@....net,  rdunlap@...radead.org,
  ilpo.jarvinen@...ux.intel.com,  kanie@...ux.alibaba.com,
  ojeda@...nel.org,  aliceryhl@...gle.com,  masahiroy@...nel.org,
  akpm@...ux-foundation.org,  tj@...nel.org,  yoann.congal@...le.fr,
  mmaurer@...gle.com,  roman.gushchin@...ux.dev,  chenridong@...wei.com,
  axboe@...nel.dk,  mark.rutland@....com,  jannh@...gle.com,
  vincent.guittot@...aro.org,  hannes@...xchg.org,
  dan.j.williams@...el.com,  david@...hat.com,  joel.granados@...nel.org,
  rostedt@...dmis.org,  anna.schumaker@...cle.com,  song@...nel.org,
  zhangguopeng@...inos.cn,  linux@...ssschuh.net,
  linux-kernel@...r.kernel.org,  linux-doc@...r.kernel.org,
  linux-mm@...ck.org,  gregkh@...uxfoundation.org,  tglx@...utronix.de,
  mingo@...hat.com,  bp@...en8.de,  dave.hansen@...ux.intel.com,
  x86@...nel.org,  hpa@...or.com,  rafael@...nel.org,  dakr@...nel.org,
  bartosz.golaszewski@...aro.org,  cw00.choi@...sung.com,
  myungjoo.ham@...sung.com,  yesanishhere@...il.com,
  Jonathan.Cameron@...wei.com,  quic_zijuhu@...cinc.com,
  aleksander.lobakin@...el.com,  ira.weiny@...el.com,
  andriy.shevchenko@...ux.intel.com,  leon@...nel.org,  lukas@...ner.de,
  bhelgaas@...gle.com,  wagi@...nel.org,  djeffery@...hat.com,
  stuart.w.hayes@...il.com
Subject: Re: [RFC v2 09/16] luo: luo_files: implement file systems callbacks

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@...een.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?

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?

>  }
>  
>  /**
> @@ -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