Hi Arnd, On Tue, 2026-01-06 at 16:37 +0100, Arnd Bergmann wrote: > On Tue, Jan 6, 2026, at 14:40, John Paul Adrian Glaubitz wrote: > > On Tue, 2026-01-06 at 14:34 +0100, Kolbjørn Barmen wrote: > > > On Mon, 16 Jun 2025, John Paul Adrian Glaubitz wrote: > > > > > > Does this patch exist somewhere? I ask because I am migrating to > > > 32bit-aligned userland (https://www.gentoo.org/downloads/#m68k) and the > > > gcc provided fails building kernel, stopping at arch/m68k/kernel/signal.c > > > > I haven't created that patch yet as my work on this effort is currently > > paused. However, it should > > be straight-forward to update the asserts in the kernel code. > > > > According to Geert, Arnd Bergmann made some changes to the kernel uapi > > that would allow the kernel > > to be built with either alignment. Not sure what the current state of > > things is. > > > > Let's CC Arnd to find out. > > I have these patches in my work-in-progress tree, and I still > plan to submit them upstream, but haven't made any progress on > it since I talked to Geert about it last month. > > See below for my current working version against roughly v6.18, > which replaces all the implicit padding in uapi header files > with explicit padding. > > What I do here is a combination of changes: > > - add -Werror=padded to the header checks to catch any > implicit padding on any architecture > - add __uapi_arch_pad8 for any 8-bit pad that is the > same on any architecture > - add __uapi_arch_pad16 for any 16-bit pad that is the > same on any architecture other than m68k > - add __uapi_arch_pad32 for any 32-bit pad for > padding between __u32 and __u64 on all architectures > that naturally align __u64 > - add __uapi_arch_pad_long between __u32 and long > (or pointer) on 64-bit architectures > - a few more specialized macros for less common corner > cases > - annotate structures as __uapi_arch_align to force 16-bit > alignment on m68k and larger alignment elsewhere, > regardless of -malign-int > > I've tested this by running the header check on all > architectures, and running the abigail tests to ensure > the ABI is unmodified (abigail is currently broken on a > few architectures). > > With all the patches applied, we get two benefits: > - m68k kernels have a consistent ABI with and without > -malign-int, so kernel and userspace can use > different setting here, and we can eventually change > the kernel to always use -malign-int > - Any new patches that introduce implicit padding in the > uapi headers break the build and get fixed before they > cause problems. Almost all the instances I've seen > are unintentional. > > I have started splitting up the change into individual > commits that explain the padding, but it will take more > work to get through the entire patch, plus any additional > changes for review comments. > > > The diffstat is > > 407 files changed, 2433 insertions(+), 754 deletions(-) > > and I think this touches around 1500 structures, though > most files only have a single one.
Wow, that's really impressive! Thanks a lot for working on this! I will definitely give it a try. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
