Re: [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve until finish
From: Pasha Tatashin
Date: Tue Nov 03 2026 - 15:36:49 EST
> The private_data field of struct liveupdate_file_op_args lets file
> handlers keep runtime state that is not preserved. It is set by
> .preserve() and passed to the later outgoing callbacks, up to
> .unpreserve(). But in the new kernel, nothing set by .retrieve() is
> kept, and .can_finish() and .finish() always get a NULL private_data.
>
> Handlers might need to keep runtime state from retrieve until finish.
> For example, memfd will need to remember the folios it holds on to
> until finish so it can release them there.
>
> Save the private_data set by a successful .retrieve() in the luo_file,
> and pass it to .can_finish() and .finish(). The handler must free it in
> .finish().
>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@xxxxxxxxxx>
> Link: https://patch.msgid.link/20261103181916.2462825-2-pratyush@xxxxxxxxxx
>
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 63ea5417de84..21caff8a98a7 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -36,9 +36,11 @@ struct file;
> * @serialized_data: The opaque u64 handle, preserve/prepare/freeze may update
> * this field.
> * @private_data: Private data for the file used to hold runtime state that
> - * is not preserved. Set by the handler's .preserve()
> - * callback, and must be freed in the handler's
> - * .unpreserve() callback.
> + * is not preserved. For outgoing, set by the handler's
> + * .preserve() callback, and must be freed in the handler's
> + * .unpreserve() callback. For incoming, set by the handler's
> + * .retrieve() callback on success, and must be freed in the
> + * handler's .finish() callback.
> *
> * This structure bundles all parameters for the file operation callbacks.
> * The 'data' and 'file' fields are used for both input and output.
Please also update the stale: 'data' argument here.
With that,
Reviewed-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
--
Pasha