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

Pasha Tatashin <[email protected]>
Newsgroups org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <178271651966.13502.2620034351625890943.b4-review@b4>
On Sun, 28 Jun 2026 00:11:14 +0000, Tarun Sahu <[email protected]> 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 <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.