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

[Eugenio Perez Martin <eperezma@redhat.com>]

On Tue, Feb 3, 2026 at 3:42 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 3, 2026, at 15:13, Eugenio Perez Martin wrote:
> > On Tue, Feb 3, 2026 at 11:35 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >> Along with it or no, surely before the release.
> >> Given 32 on 64 with this apparently has been broken forever,
> >> I will merge this just based on even you did not bother testing compat, I am
> >> inclined to say I am merging this but not rebasing because
> >> of this.
> >>
> >> Oh and we got lucky this didn't leak kernel stack info.
> >>
> >> Eugenio, note for the future: please help make sure UAPI
> >> structs do not have hidden padding.
> >>
> >
> > Sure. I'm trying to find an automatic way to check for this but with
> > no luck :(. Arnd, did you use some tool for this or you just found it
> > by visual inspection? I'm trying pahole and -Wpadded but the output
> > includes a lot of struct not related to uapi.
> >
> > I guess it is possible to filter it with some clang or awk machinery,
> > but I'm asking in case I avoid developing something already existing.
>
> I have the patch series, but it's not quite ready for submission.
> In total, I annotated around 10% of the structure definitions
> (500 files) in include/uapi/ to shut up -Wpadded for all the
> existing structures with holes in them.
>
> In the end I turn on the check with
>
> --- a/usr/include/Makefile
> +++ b/usr/include/Makefile
> @@ -6,7 +6,7 @@
>  #
>  # -std=c90 (equivalent to -ansi) catches the violation of those.
>  # We cannot go as far as adding -Wpedantic since it emits too many warnings.
> -UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration
> +UAPI_CFLAGS := -std=c90 -Werror=implicit-function-declaration -Werror=padded
>
>  # when cross-compiling with a minimal toolchain, use nolibc headers
>  UAPI_CFLAGS += -I$(srctree)/tools/include/nolibc/
>
> which of course warns for all the existing holes. I will continue
> to send fixes for new instances in the meantime, as I'm testing
> linux-next.
>

Got it, to develop something in parallel would be to duplicate work
then. Looking forward to it then, thank you very much!