On Mon, Feb 02, 2026 at 12:59:03PM +0100, Arnd Bergmann wrote: > On Mon, Feb 2, 2026, at 12:34, Eugenio Perez Martin wrote: > > On Mon, Feb 2, 2026 at 11:07 AM Arnd Bergmann <[email protected]> wrote: > >> > >> From: Arnd Bergmann <[email protected]> > >> > >> 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
I think .compat_ioctl would be cleaner frankly. Just look at all the ifdefery. And who knows what broken-ness userspace comes up with with this approach. Better use the standard approach.
