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