On Tue, Feb 3, 2026, at 15:13, Eugenio Perez Martin wrote:
> On Tue, Feb 3, 2026 at 11:35 AM Michael S. Tsirkin <[email protected]> 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.
Arnd
