Re: [PATCH 2/2] vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Feb 2, 2026, at 12:34, Eugenio Perez Martin wrote:
> On Mon, Feb 2, 2026 at 11:07 AM Arnd Bergmann <arnd@kernel.org> wrote:
>>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> These two ioctls are incompatible on 32-bit x86 userspace, because
>> the data structures are shorter than they are on 64-bit.
>>
>> Add compad handling to the regular ioctl handler to just handle
>> them the same way and ignore the extra padding. This could be
>> done in a separate .compat_ioctl handler, but the main one already
>> handles two versions of VDUSE_IOTLB_GET_FD, so adding a third one
>> fits in rather well.
>>
>
> I'm just learning about the COMPAT_ stuff but does this mean the
> userland app need to call a different ioctl depending if it is
> compiled for 32 bits or 64 bits? I guess it is not the case, but how
> is that handled?

In a definition like

#define VDUSE_IOTLB_GET_FD      _IOWR(VDUSE_BASE, 0x10, struct vduse_iotlb_entry)

The resulting integer value encodes sizeof(struct vduse_iotlb_entry)
in some of the bits. Since x86-32 and x86-64 have different
sizes for this particular structure, the command codes are
different for the same macro. The recommendation from 
Documentation/driver-api/ioctl.rst is to use structures with
a consistent layout across all architectures to avoid that.

The normal way to handle this once it has gone wrong is to split
out the actual handler into a function that takes the kernel
structure, and a .compat_ioctl() handler that copies the
32-bit structure to the stack in the correct format.

Since the v1 structures here are /almost/ compatible aside from
the padding at the end, my patch here takes a shortcut and does
not add a custom .compat_ioctl handler but instead changes
the native version on x86-64 to deal with both layouts.
This does mean that the kernel driver now also accepts the
64-bit layout coming from compat tasks, and the compat layout
coming from 64-bit tasks.

Nothing in userspace changes, as it still just uses the existing
VDUSE_IOTLB_GET_FD macro, and the kernel continues to handle
the native layout as before.

    Arnd