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

[tarunsahu@google.com]

Hello,

I dont have much opinion here. I am writing this as a
gentle reminder to the open discussion below.

~Tarun

Pratyush Yadav <pratyush@kernel.org> writes:

> 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