On Tue, Mar 5, 2024, at 20:22, Mina Almasry wrote:
On Tue, Mar 5, 2024 at 12:42 AM Arnd Bergmann arnd@arndb.de 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