The latest binutils stopped aligning section data in relocatable ELF.
It saves small number of bytes that were previously inserted between
sections. However, modpost crashes due to unaligned access:
  https://sourceware.org/bugzilla/show_bug.cgi?id=32435
  https://sourceware.org/bugzilla/show_bug.cgi?id=32493

Similar to kernel space, unaligned data access in userspace can be
problematic on some architectures.

Simple example on ARM:

 $ CC=arm-linux-gnueabihf-gcc
 $ echo 'int foo(int *p) { return *p + *(p + 1); }' | ${CC} -O2 -x c - -c -o foo.o
 $ echo 'int foo(int *p); int main(void) { char str[16] = "helloworld"; return foo((int *)(str + 1)); }' | ${CC} -x c - -c -o main.o
 $ ${CC} -static -o unalign-test main.o foo.o
 $ qemu-armhf unalign-test
 qemu: uncaught target signal 7 (Bus error) - core dumped
 Bus error (core dumped)

In this case, the 'ldrd' instruction causes a bus error due to an
unaligned access. If the -O2 flag is omitted, this issue does not occur.

To avoid potential unaligned access, use the get_unaligned() approach
as seen in the kernel space.



Masahiro Yamada (3):
  modpost: fix the missed iteration for the max bit in do_input()
  modpost: refactor do_vmbus_entry()
  modpost: work around unaligned data access error

 scripts/mod/file2alias.c | 36 +++++++++++++++++-------------------
 scripts/mod/modpost.c    | 24 ++++++++++++------------
 scripts/mod/modpost.h    | 14 ++++++++++++++
 3 files changed, 43 insertions(+), 31 deletions(-)

-- 
2.43.0

Hi Masahiro,

> The latest binutils stopped aligning section data in relocatable ELF.
> It saves small number of bytes that were previously inserted between
> sections. However, modpost crashes due to unaligned access:
>   https://sourceware.org/bugzilla/show_bug.cgi?id=32435
>   https://sourceware.org/bugzilla/show_bug.cgi?id=32493
>
> Similar to kernel space, unaligned data access in userspace can be
> problematic on some architectures.
>
> Simple example on ARM:
>
>  $ CC=arm-linux-gnueabihf-gcc
>  $ echo 'int foo(int *p) { return *p + *(p + 1); }' | ${CC} -O2 -x c - -c -o foo.o
>  $ echo 'int foo(int *p); int main(void) { char str[16] = "helloworld"; return foo((int *)(str + 1)); }' | ${CC} -x c - -c -o main.o
>  $ ${CC} -static -o unalign-test main.o foo.o
>  $ qemu-armhf unalign-test
>  qemu: uncaught target signal 7 (Bus error) - core dumped
>  Bus error (core dumped)
>
> In this case, the 'ldrd' instruction causes a bus error due to an
> unaligned access. If the -O2 flag is omitted, this issue does not occur.
>
> To avoid potential unaligned access, use the get_unaligned() approach
> as seen in the kernel space.

I have just applied this series against Linus' tree and I can confirm that it fixes the
unalignment access anymore on sparc64. There is no more "Bus error" and the build succeeds.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

On Thu, Dec 26, 2024 at 1:27 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> Hi Masahiro,
>
> > The latest binutils stopped aligning section data in relocatable ELF.
> > It saves small number of bytes that were previously inserted between
> > sections. However, modpost crashes due to unaligned access:
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=32435
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=32493
> >
> > Similar to kernel space, unaligned data access in userspace can be
> > problematic on some architectures.
> >
> > Simple example on ARM:
> >
> >  $ CC=arm-linux-gnueabihf-gcc
> >  $ echo 'int foo(int *p) { return *p + *(p + 1); }' | ${CC} -O2 -x c - -c -o foo.o
> >  $ echo 'int foo(int *p); int main(void) { char str[16] = "helloworld"; return foo((int *)(str + 1)); }' | ${CC} -x c - -c -o main.o
> >  $ ${CC} -static -o unalign-test main.o foo.o
> >  $ qemu-armhf unalign-test
> >  qemu: uncaught target signal 7 (Bus error) - core dumped
> >  Bus error (core dumped)
> >
> > In this case, the 'ldrd' instruction causes a bus error due to an
> > unaligned access. If the -O2 flag is omitted, this issue does not occur.
> >
> > To avoid potential unaligned access, use the get_unaligned() approach
> > as seen in the kernel space.
>
> I have just applied this series against Linus' tree and I can confirm that it fixes the
> unalignment access anymore on sparc64. There is no more "Bus error" and the build succeeds.
>
> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>


Thanks for the compile test.

Loadable modules (*.ko files) are relocatable ELF.
So, there is no alignment in *.ko files any more
if the latest binutils is used.

Just in case, I did run-tests for arm and arm64.
Even if there is no alignment in *.ko files,
I confirmed that the kernel can load modules.

If you have time, please run-test and
double-check loadable modules are working.



-- 
Best Regards
Masahiro Yamada

Hi Masahiro,

On Thu, 2024-12-26 at 22:55 +0900, Masahiro Yamada wrote:
> > I have just applied this series against Linus' tree and I can confirm that it fixes the
> > unalignment access anymore on sparc64. There is no more "Bus error" and the build succeeds.
> > 
> > Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> 
> 
> Thanks for the compile test.
> 
> Loadable modules (*.ko files) are relocatable ELF.
> So, there is no alignment in *.ko files any more
> if the latest binutils is used.
> 
> Just in case, I did run-tests for arm and arm64.
> Even if there is no alignment in *.ko files,
> I confirmed that the kernel can load modules.
> 
> If you have time, please run-test and
> double-check loadable modules are working.

I have just verified that. I applied your series against v6.13-rc4 and can confirm
that module loading works without any issues on sparc64. Tested on SPARC T5 LDOM.

So, please extend my Tested-By to both compile and runtime testing on sparc64.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913