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

["Michael S. Tsirkin" <mst@redhat.com>]

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 <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

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.