On Tue, Mar 5, 2024, at 20:22, Mina Almasry wrote:
> On Tue, Mar 5, 2024 at 12:42 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Tue, Mar 5, 2024, at 03:01, Mina Almasry wrote:
>>
>> This structure requires a special compat handler to run
>> x86-32 binaries on x86-64 because of the different alignment
>> requirements. Any uapi-visible structures should be defined
>> to avoid this and just have no holes in them. Maybe extend
>> one of the __u32 members to __u64 or add another 32-bit padding field?
>>
>
> Honestly the 32-bit fields as-is are somewhat comically large. I don't
> think extending the __u32 -> __u64 is preferred because I don't see us
> needing that much, so maybe I can add another 32-bit padding field.
> Does this look good to you?
Having a reserved field works but requires that you check it for
being zero already, so you can detect an incompatible caller.
> struct dmabuf_cmsg {
> __u64 frag_offset;
> __u32 frag_size;
> __u32 frag_token;
> __u32 dmabuf_id;
> __u32 ext; /* reserved for future flags */
> };
Maybe call it 'flags'?
> Another option is to actually compress frag_token & dmabuf_id to be
> 32-bit combined size if that addresses your concern. I prefer that
> less in case they end up being too small for future use cases.
I don't know what either of those fields is. Is dmabuf_id not a
file descriptor? If it is, it has to be 32 bits wide. Otherwise
having two 16-bit fields and a 32-bit field would indeed add up
to a multiple of the structure alignment on all architectures and
solve the problem.
Arnd
