[PATCH v6 3/3] luo: Update serialized data to use KHOSER_PTR

Pasha Tatashin pasha.tatashin at soleen.com
Mon Jun 29 00:01:59 PDT 2026


On Sun, 28 Jun 2026 00:11:14 +0000, Tarun Sahu <tarunsahu at google.com> wrote:
> diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
> index 288076de6d4a..9e78625cfdc1 100644
> --- a/include/linux/kho/abi/luo.h
> +++ b/include/linux/kho/abi/luo.h
> @@ -89,14 +90,14 @@ struct luo_ser {
>  /**
>   * struct luo_file_ser - Represents the serialized preserves files.
>   * @compatible:  File handler compatible string.
> - * @data:        Private data
> + * @serialized_data:  The serialized KHO pointer for this file

I am concerned about layring violation here.

LUO is designed as  a generic, opaque transport layer that promises to 
preserve 64 bits of raw data. How those 64 bits are interpreted is 
entirely up to individual clients.

While some clients like memfd_luo will use those 64 bits as a physical 
address pointing to KHO-preserved structures, other clients may store a 
generic token, cookie, index, or non-pointer status. By
changing u64 data to DECLARE_KHOSER_PTR(serialized_data, void *) in 
struct luo_file_ser, we force KHO pointer semantics and layout 
constraints on all generic LUO files.

Clients that need KHO pointer serialization must cast that opaque 64-bit 
value to/from a  KHOSER_PTR  within their own callbacks.

Also, the field descriptions in  struct luo_file_ser  are no longer 
aligned due to the length of the new variable name, I believe it will 
cause warning when making docs.

-- 
Pasha Tatashin <pasha.tatashin at soleen.com>



More information about the kexec mailing list