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]>
