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

[Pasha Tatashin <pasha.tatashin@soleen.com>]

On 07-09 12:20, Pratyush Yadav wrote:
> Hi Pasha,
> 
> On Mon, Jun 29 2026, Pasha Tatashin wrote:
> 
> > On Sun, 28 Jun 2026 00:11:14 +0000, Tarun Sahu <tarunsahu@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.
> 
> That makes sense theory, but in practice, no file handler is going to
> need only 8 bytes for its metadata. It is always going to need more, and
> to store more information, it needs to store a pointer to that
> information with the 64 bits it gets.
> 
> Do you have any examples of something else one might store here?
> 
> At least looking at the current file handlers merged and in flight,
> memfd, iommufd, vfio, pci, hugetlb, guest_memfd, all of them store a
> pointer here.

Right, and all of those types are private to file-handlers, not to LUO, 
so my question is:

> 
> And if everyone is only storing pointers in this field, might as well
> give them a bit of type safety.

How khoser helps void * type?

Pasha

> 
> >
> > 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.
> 
> -- 
> Regards,
> Pratyush Yadav