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

[Pratyush Yadav <pratyush@kernel.org>]

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.

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

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