All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] Fix __kcrctab+* sections alignment
@ 2022-08-17 16:14 Yann Sionneau
  2022-08-17 16:14 ` [RFC PATCH 1/1] " Yann Sionneau
  2022-08-25 12:03 ` Fwd: [RFC PATCH 0/1] " Yann Sionneau
  0 siblings, 2 replies; 18+ messages in thread
From: Yann Sionneau @ 2022-08-17 16:14 UTC (permalink / raw)
  To: linux-kernel
  Cc: Nicolas Schier, Masahiro Yamada, Jules Maselbas, Julian Vetter,
	Yann Sionneau

Hello, 
At Kalray we have our (non-upstreamed-yet) kvx Linux port (https://github.com/kalray/linux_coolidge).

When I did the rebase on 5.19 I noticed the kernel module would not load anymore and would say

[   10.071771] Found checksum 0 vs module B4E7D8E
[   10.071824] libphy: disagrees about version of symbol module_layout

The CRC of module_layout in libphy.ko seems fine, but surprisingly, the CRC of module_layout in vmlinux is 0.

I dig a little bit to try and understand why.

.vmlinux.export.c contains:
SYMBOL_CRC(module_layout, 0x0b4e7d8e, "");

Dumping the section '___kcrctab+module_layout' of .vmlinux.export.o I get:
Hex dump of section '___kcrctab+module_layout':
  0x00000000 8e7d4e0b                            .}N.

Dumping __kcrctab section of vmlinux:
Hex dump of section '__kcrctab':
  0xffffff80055b7090 572828d0 00000000 b96e414c 00000000 W((......nAL....
  0xffffff80055b70a0 b0179638 00000000 e3eb8db7 00000000 ...8............
  0xffffff80055b70b0 7a10c1c7 00000000 3d04478a 00000000 z.......=.G.....
  0xffffff80055b70c0 a5d7be15 00000000 d188008b 00000000 ................
  0xffffff80055b70d0 6214323b 00000000 bba48601 00000000 b.2;............
  0xffffff80055b70e0 6bfbba55 00000000 251fa090 00000000 k..U....%.......
  0xffffff80055b70f0 2861bde8 00000000 81c8241d 00000000 (a........$.....
etc

You can see that in fact there is some kind of 4-bytes padding in-between each CRC32.

And indeed by looking at ___kcrctab+module_layout section alignment in .vmlinux.export.o I can see:
  Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [...snip snip...]
  [6189] ___kcrctab+module_layout PROGBITS        0000000000000000 00c188 000004 00  WA  0   0  8

So somehow, the section really contains 4 bytes of the CRC32 but even though the section contains a u32, the toolchain creates an 8-bytes aligned section.
This ends up creating 4-bytes padding with 0s once the linker collects all those ___kcrctab+* into __kcrctab for vmlinux ELF.

Do you think this is an issue in Linux kernel generic code? (See attached patch that makes our module probe again)
Or is this an issue with our toolchain?

On 5.16.20 our modules were loading fine and the __kcrctab did not contain any 4-bytes 00000000 gaps.
I think it is related to this change: https://lore.kernel.org/linux-kbuild/20220528224745.GA2501857@roeck-us.net/T/
In the change, we can see that the previous version was using assembly to create the sections and there was the presence of a ".balign KCRC_ALIGN" which was defined to whatever is the arch-specific way to encode a "4 bytes" alignement (be it 2 for "2^2" for m68k or directly 4 for others) for the assembler.

How to reproduce:
1/ generate the toolchain
$ git clone https://github.com/kalray/build-scripts
$ cd build-scripts
$ source last.refs
$ ./build-kvx-xgcc.sh output

2/ fetch and build our v5.19 kernel
$ git clone -b kalray-linux-v5.19 https://github.com/kalray/linux_coolidge
$ cd linux_coolidge
$ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- default_defconfig
$ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- -j$(($(nproc) + 1))

You won't have a rootfs but you will be able to observe the content of __kcrctab section of vmlinux
PS: the kalray-linux-v5.19 branch already contains the attached-patch to add __aligned(4) requirement.
PPS: Please CC me, I am not subscribed to the mailing list

Yann Sionneau (1):
  Fix __kcrctab+* sections alignment

 include/linux/export-internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.37.2






^ permalink raw reply	[flat|nested] 18+ messages in thread

* [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-17 16:14 [RFC PATCH 0/1] Fix __kcrctab+* sections alignment Yann Sionneau
@ 2022-08-17 16:14 ` Yann Sionneau
  2022-08-25 12:03   ` Fwd: " Yann Sionneau
  2022-08-25 12:03 ` Fwd: [RFC PATCH 0/1] " Yann Sionneau
  1 sibling, 1 reply; 18+ messages in thread
From: Yann Sionneau @ 2022-08-17 16:14 UTC (permalink / raw)
  To: linux-kernel
  Cc: Nicolas Schier, Masahiro Yamada, Jules Maselbas, Julian Vetter,
	Yann Sionneau

Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
---
 include/linux/export-internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index c2b1d4fd5987..d86bfbd7fa6d 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -12,6 +12,6 @@
 
 /* __used is needed to keep __crc_* for LTO */
 #define SYMBOL_CRC(sym, crc, sec)   \
-	u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
+	u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4) __crc_##sym = crc
 
 #endif /* __LINUX_EXPORT_INTERNAL_H__ */
-- 
2.37.2






^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Fwd: [RFC PATCH 0/1] Fix __kcrctab+* sections alignment
  2022-08-17 16:14 [RFC PATCH 0/1] Fix __kcrctab+* sections alignment Yann Sionneau
  2022-08-17 16:14 ` [RFC PATCH 1/1] " Yann Sionneau
@ 2022-08-25 12:03 ` Yann Sionneau
  1 sibling, 0 replies; 18+ messages in thread
From: Yann Sionneau @ 2022-08-25 12:03 UTC (permalink / raw)
  To: linux-kbuild, linux-arch

Forwarding to linux-kbuild and linux-arch


-------- Forwarded Message --------
Subject: 	[RFC PATCH 0/1] Fix __kcrctab+* sections alignment
Date: 	Wed, 17 Aug 2022 18:14:37 +0200
From: 	Yann Sionneau <ysionneau@kalray.eu>
To: 	linux-kernel@vger.kernel.org
CC: 	Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada 
<masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian 
Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>



Hello, At Kalray we have our (non-upstreamed-yet) kvx Linux port 
(https://github.com/kalray/linux_coolidge).

When I did the rebase on 5.19 I noticed the kernel module would not load 
anymore and would say

[ 10.071771] Found checksum 0 vs module B4E7D8E
[ 10.071824] libphy: disagrees about version of symbol module_layout

The CRC of module_layout in libphy.ko seems fine, but surprisingly, the 
CRC of module_layout in vmlinux is 0.

I dig a little bit to try and understand why.

.vmlinux.export.c contains:
SYMBOL_CRC(module_layout, 0x0b4e7d8e, "");

Dumping the section '___kcrctab+module_layout' of .vmlinux.export.o I get:
Hex dump of section '___kcrctab+module_layout':
0x00000000 8e7d4e0b .}N.

Dumping __kcrctab section of vmlinux:
Hex dump of section '__kcrctab':
0xffffff80055b7090 572828d0 00000000 b96e414c 00000000 W((......nAL....
0xffffff80055b70a0 b0179638 00000000 e3eb8db7 00000000 ...8............
0xffffff80055b70b0 7a10c1c7 00000000 3d04478a 00000000 z.......=.G.....
0xffffff80055b70c0 a5d7be15 00000000 d188008b 00000000 ................
0xffffff80055b70d0 6214323b 00000000 bba48601 00000000 b.2;............
0xffffff80055b70e0 6bfbba55 00000000 251fa090 00000000 k..U....%.......
0xffffff80055b70f0 2861bde8 00000000 81c8241d 00000000 (a........$.....
etc

You can see that in fact there is some kind of 4-bytes padding 
in-between each CRC32.

And indeed by looking at ___kcrctab+module_layout section alignment in 
.vmlinux.export.o I can see:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[...snip snip...]
[6189] ___kcrctab+module_layout PROGBITS 0000000000000000 00c188 000004 
00 WA 0 0 8

So somehow, the section really contains 4 bytes of the CRC32 but even 
though the section contains a u32, the toolchain creates an 8-bytes 
aligned section.
This ends up creating 4-bytes padding with 0s once the linker collects 
all those ___kcrctab+* into __kcrctab for vmlinux ELF.

Do you think this is an issue in Linux kernel generic code? (See 
attached patch that makes our module probe again)
Or is this an issue with our toolchain?

On 5.16.20 our modules were loading fine and the __kcrctab did not 
contain any 4-bytes 00000000 gaps.
I think it is related to this change: 
https://lore.kernel.org/linux-kbuild/20220528224745.GA2501857@roeck-us.net/T/
In the change, we can see that the previous version was using assembly 
to create the sections and there was the presence of a ".balign 
KCRC_ALIGN" which was defined to whatever is the arch-specific way to 
encode a "4 bytes" alignement (be it 2 for "2^2" for m68k or directly 4 
for others) for the assembler.

How to reproduce:
1/ generate the toolchain
$ git clone https://github.com/kalray/build-scripts
$ cd build-scripts
$ source last.refs
$ ./build-kvx-xgcc.sh output

2/ fetch and build our v5.19 kernel
$ git clone -b kalray-linux-v5.19 https://github.com/kalray/linux_coolidge
$ cd linux_coolidge
$ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- default_defconfig
$ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- -j$(($(nproc) + 1))

You won't have a rootfs but you will be able to observe the content of 
__kcrctab section of vmlinux
PS: the kalray-linux-v5.19 branch already contains the attached-patch to 
add __aligned(4) requirement.
PPS: Please CC me, I am not subscribed to the mailing list

Yann Sionneau (1):
Fix __kcrctab+* sections alignment

include/linux/export-internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.37.2






^ permalink raw reply	[flat|nested] 18+ messages in thread

* Fwd: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-17 16:14 ` [RFC PATCH 1/1] " Yann Sionneau
@ 2022-08-25 12:03   ` Yann Sionneau
  2022-08-25 12:12     ` Ard Biesheuvel
  0 siblings, 1 reply; 18+ messages in thread
From: Yann Sionneau @ 2022-08-25 12:03 UTC (permalink / raw)
  To: linux-kbuild, linux-arch

Forwarding also the actual patch to linux-kbuild and linux-arch

-------- Forwarded Message --------
Subject: 	[RFC PATCH 1/1] Fix __kcrctab+* sections alignment
Date: 	Wed, 17 Aug 2022 18:14:38 +0200
From: 	Yann Sionneau <ysionneau@kalray.eu>
To: 	linux-kernel@vger.kernel.org
CC: 	Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada 
<masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian 
Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>



Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
---
include/linux/export-internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/export-internal.h 
b/include/linux/export-internal.h
index c2b1d4fd5987..d86bfbd7fa6d 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -12,6 +12,6 @@
/* __used is needed to keep __crc_* for LTO */
#define SYMBOL_CRC(sym, crc, sec) \
- u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
+ u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4) 
__crc_##sym = crc
#endif /* __LINUX_EXPORT_INTERNAL_H__ */

-- 
2.37.2






^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 12:03   ` Fwd: " Yann Sionneau
@ 2022-08-25 12:12     ` Ard Biesheuvel
  2022-08-25 12:21       ` Yann Sionneau
  0 siblings, 1 reply; 18+ messages in thread
From: Ard Biesheuvel @ 2022-08-25 12:12 UTC (permalink / raw)
  To: Yann Sionneau; +Cc: linux-kbuild, linux-arch

On Thu, 25 Aug 2022 at 14:10, Yann Sionneau <ysionneau@kalray.eu> wrote:
>
> Forwarding also the actual patch to linux-kbuild and linux-arch
>
> -------- Forwarded Message --------
> Subject:        [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
> Date:   Wed, 17 Aug 2022 18:14:38 +0200
> From:   Yann Sionneau <ysionneau@kalray.eu>
> To:     linux-kernel@vger.kernel.org
> CC:     Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada
> <masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian
> Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>
>
>
>

What happened to the commit log?

> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
> ---
> include/linux/export-internal.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/export-internal.h
> b/include/linux/export-internal.h
> index c2b1d4fd5987..d86bfbd7fa6d 100644
> --- a/include/linux/export-internal.h
> +++ b/include/linux/export-internal.h
> @@ -12,6 +12,6 @@
> /* __used is needed to keep __crc_* for LTO */
> #define SYMBOL_CRC(sym, crc, sec) \
> - u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> + u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4)

__aligned(4) is the default for u32 so this should not be needed.


> __crc_##sym = crc
> #endif /* __LINUX_EXPORT_INTERNAL_H__ */
>
> --
> 2.37.2
>
>
>
>
>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 12:12     ` Ard Biesheuvel
@ 2022-08-25 12:21       ` Yann Sionneau
  2022-08-25 12:41         ` Ard Biesheuvel
                           ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Yann Sionneau @ 2022-08-25 12:21 UTC (permalink / raw)
  To: Ard Biesheuvel; +Cc: linux-kbuild, linux-arch

Hello Ard,

On 25/08/2022 14:12, Ard Biesheuvel wrote:
> On Thu, 25 Aug 2022 at 14:10, Yann Sionneau <ysionneau@kalray.eu> wrote:
>> Forwarding also the actual patch to linux-kbuild and linux-arch
>>
>> -------- Forwarded Message --------
>> Subject:        [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
>> Date:   Wed, 17 Aug 2022 18:14:38 +0200
>> From:   Yann Sionneau <ysionneau@kalray.eu>
>> To:     linux-kernel@vger.kernel.org
>> CC:     Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada
>> <masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian
>> Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>
>>
>>
>>
> What happened to the commit log?

This is a forward of this thread: https://lkml.org/lkml/2022/8/17/868

Either I did something wrong with my email agent or maybe the email 
containing the cover letter is taking some time to reach you?

>
>> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
>> ---
>> include/linux/export-internal.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/export-internal.h
>> b/include/linux/export-internal.h
>> index c2b1d4fd5987..d86bfbd7fa6d 100644
>> --- a/include/linux/export-internal.h
>> +++ b/include/linux/export-internal.h
>> @@ -12,6 +12,6 @@
>> /* __used is needed to keep __crc_* for LTO */
>> #define SYMBOL_CRC(sym, crc, sec) \
>> - u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
>> + u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4)
> __aligned(4) is the default for u32 so this should not be needed.

Well, I am not completely sure about that. See my cover letter, previous 
mechanism for symbol CRC was actually enforcing the section alignment to 
4 bytes boundary as well.

Also, I'm not sure it is forbidden for an architecture/compiler 
implementation to actually enforce a stronger alignment on u32, which in 
theory would not break anything.

But in this precise case it does break something since it will cause 
"gaps" in the end result vmlinux binary segment. For this to work I 
think we really want to enforce a 4 bytes alignment on the section.

>
>
>> __crc_##sym = crc
>> #endif /* __LINUX_EXPORT_INTERNAL_H__ */
>>
>> --
>> 2.37.2

Thanks for your review :)

-- 

Yann






^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 12:21       ` Yann Sionneau
@ 2022-08-25 12:41         ` Ard Biesheuvel
  2022-08-25 18:01           ` Geert Uytterhoeven
  2022-08-28 13:41         ` Masahiro Yamada
  2022-08-28 13:59         ` Masahiro Yamada
  2 siblings, 1 reply; 18+ messages in thread
From: Ard Biesheuvel @ 2022-08-25 12:41 UTC (permalink / raw)
  To: Yann Sionneau, Arnd Bergmann; +Cc: linux-kbuild, linux-arch

(cc Arnd)

On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
>
> Hello Ard,
>
> On 25/08/2022 14:12, Ard Biesheuvel wrote:
> > On Thu, 25 Aug 2022 at 14:10, Yann Sionneau <ysionneau@kalray.eu> wrote:
> >> Forwarding also the actual patch to linux-kbuild and linux-arch
> >>
> >> -------- Forwarded Message --------
> >> Subject:        [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
> >> Date:   Wed, 17 Aug 2022 18:14:38 +0200
> >> From:   Yann Sionneau <ysionneau@kalray.eu>
> >> To:     linux-kernel@vger.kernel.org
> >> CC:     Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada
> >> <masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian
> >> Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>
> >>
> >>
> >>
> > What happened to the commit log?
>
> This is a forward of this thread: https://lkml.org/lkml/2022/8/17/868
>
> Either I did something wrong with my email agent or maybe the email
> containing the cover letter is taking some time to reach you?
>

Never mind, i see the other thread as well.

Exec summary: out-of-tree port for kvx architecture appears to impose
8 byte alignment for u32 types in some cases.

> >
> >> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
> >> ---
> >> include/linux/export-internal.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/export-internal.h
> >> b/include/linux/export-internal.h
> >> index c2b1d4fd5987..d86bfbd7fa6d 100644
> >> --- a/include/linux/export-internal.h
> >> +++ b/include/linux/export-internal.h
> >> @@ -12,6 +12,6 @@
> >> /* __used is needed to keep __crc_* for LTO */
> >> #define SYMBOL_CRC(sym, crc, sec) \
> >> - u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> >> + u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4)

> > __aligned(4) is the default for u32 so this should not be needed.

>
> Well, I am not completely sure about that. See my cover letter, previous
> mechanism for symbol CRC was actually enforcing the section alignment to
> 4 bytes boundary as well.
>
> Also, I'm not sure it is forbidden for an architecture/compiler
> implementation to actually enforce a stronger alignment on u32, which in
> theory would not break anything.
>

u32 is a Linux type, and Linux expects natural alignment (and padding).

So if your toolchain/architecture violates this rule, I suggest you
typedef u32 to 'unsigned int __aligned(4)' explicitly. so that things
don't break in other places.

However, even then, I am highly skeptical. This really seems like an
issue in your toolchain that could cause problems all over the place.

> But in this precise case it does break something since it will cause
> "gaps" in the end result vmlinux binary segment. For this to work I
> think we really want to enforce a 4 bytes alignment on the section.
>

You are addressing one of many potential issues that could be caused
by this, so I don't think this patch is a good idea tbh.


> >
> >
> >> __crc_##sym = crc
> >> #endif /* __LINUX_EXPORT_INTERNAL_H__ */
> >>
> >> --
> >> 2.37.2
>
> Thanks for your review :)
>
> --
>
> Yann
>
>
>
>
>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 12:41         ` Ard Biesheuvel
@ 2022-08-25 18:01           ` Geert Uytterhoeven
  2022-08-26 10:17             ` Ard Biesheuvel
  0 siblings, 1 reply; 18+ messages in thread
From: Geert Uytterhoeven @ 2022-08-25 18:01 UTC (permalink / raw)
  To: Ard Biesheuvel; +Cc: Yann Sionneau, Arnd Bergmann, linux-kbuild, Linux-Arch

Hi Ard,

On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
> > Well, I am not completely sure about that. See my cover letter, previous
> > mechanism for symbol CRC was actually enforcing the section alignment to
> > 4 bytes boundary as well.

Yes, because else it may become 2-byte aligned on m68k.

> > Also, I'm not sure it is forbidden for an architecture/compiler
> > implementation to actually enforce a stronger alignment on u32, which in
> > theory would not break anything.
> >
>
> u32 is a Linux type, and Linux expects natural alignment (and padding).

Is it? You probably mean its alignment should not be larger than
4 bytes? Less has been working since basically forever.

> So if your toolchain/architecture violates this rule, I suggest you
> typedef u32 to 'unsigned int __aligned(4)' explicitly. so that things
> don't break in other places.
>
> However, even then, I am highly skeptical. This really seems like an
> issue in your toolchain that could cause problems all over the place.
>
> > But in this precise case it does break something since it will cause
> > "gaps" in the end result vmlinux binary segment. For this to work I
> > think we really want to enforce a 4 bytes alignment on the section.
>
> You are addressing one of many potential issues that could be caused
> by this, so I don't think this patch is a good idea tbh.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 18:01           ` Geert Uytterhoeven
@ 2022-08-26 10:17             ` Ard Biesheuvel
  2022-08-28 14:05               ` Masahiro Yamada
  0 siblings, 1 reply; 18+ messages in thread
From: Ard Biesheuvel @ 2022-08-26 10:17 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Yann Sionneau, Arnd Bergmann, linux-kbuild, Linux-Arch

On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ard,
>
> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
> > > Well, I am not completely sure about that. See my cover letter, previous
> > > mechanism for symbol CRC was actually enforcing the section alignment to
> > > 4 bytes boundary as well.
>
> Yes, because else it may become 2-byte aligned on m68k.
>
> > > Also, I'm not sure it is forbidden for an architecture/compiler
> > > implementation to actually enforce a stronger alignment on u32, which in
> > > theory would not break anything.
> > >
> >
> > u32 is a Linux type, and Linux expects natural alignment (and padding).
>
> Is it? You probably mean its alignment should not be larger than
> 4 bytes? Less has been working since basically forever.
>

You are quite right. of course. And indeed, the issue here is padding
not alignment.


> > So if your toolchain/architecture violates this rule, I suggest you
> > typedef u32 to 'unsigned int __aligned(4)' explicitly. so that things
> > don't break in other places.
> >
> > However, even then, I am highly skeptical. This really seems like an
> > issue in your toolchain that could cause problems all over the place.
> >
> > > But in this precise case it does break something since it will cause
> > > "gaps" in the end result vmlinux binary segment. For this to work I
> > > think we really want to enforce a 4 bytes alignment on the section.
> >
> > You are addressing one of many potential issues that could be caused
> > by this, so I don't think this patch is a good idea tbh.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 12:21       ` Yann Sionneau
  2022-08-25 12:41         ` Ard Biesheuvel
@ 2022-08-28 13:41         ` Masahiro Yamada
  2022-08-28 13:59         ` Masahiro Yamada
  2 siblings, 0 replies; 18+ messages in thread
From: Masahiro Yamada @ 2022-08-28 13:41 UTC (permalink / raw)
  To: Yann Sionneau; +Cc: Ard Biesheuvel, Linux Kbuild mailing list, linux-arch

On Thu, Aug 25, 2022 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote:
>
> Hello Ard,
>
> On 25/08/2022 14:12, Ard Biesheuvel wrote:
> > On Thu, 25 Aug 2022 at 14:10, Yann Sionneau <ysionneau@kalray.eu> wrote:
> >> Forwarding also the actual patch to linux-kbuild and linux-arch
> >>
> >> -------- Forwarded Message --------
> >> Subject:        [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
> >> Date:   Wed, 17 Aug 2022 18:14:38 +0200
> >> From:   Yann Sionneau <ysionneau@kalray.eu>
> >> To:     linux-kernel@vger.kernel.org
> >> CC:     Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada
> >> <masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian
> >> Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>
> >>
> >>
> >>
> > What happened to the commit log?
>
> This is a forward of this thread: https://lkml.org/lkml/2022/8/17/868
>
> Either I did something wrong with my email agent or maybe the email
> containing the cover letter is taking some time to reach you?
>
> >
> >> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
> >> ---
> >> include/linux/export-internal.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/export-internal.h
> >> b/include/linux/export-internal.h
> >> index c2b1d4fd5987..d86bfbd7fa6d 100644
> >> --- a/include/linux/export-internal.h
> >> +++ b/include/linux/export-internal.h
> >> @@ -12,6 +12,6 @@
> >> /* __used is needed to keep __crc_* for LTO */
> >> #define SYMBOL_CRC(sym, crc, sec) \
> >> - u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> >> + u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4)
> > __aligned(4) is the default for u32 so this should not be needed.
>
> Well, I am not completely sure about that. See my cover letter, previous
> mechanism for symbol CRC was actually enforcing the section alignment to
> 4 bytes boundary as well.

I do not think so.


I do not see such alignment in for __CRC_SYMBOL() in
include/linux/export.h

If you are talking about KCRC_ALIGN
in include/asm-generic/export.h, it is only used by *.S.


Most of EXPORT_SYMBOL's are defined in *.c files,
which include <linux/export.h>

If I am missing something, please point me to the code.








>
> Also, I'm not sure it is forbidden for an architecture/compiler
> implementation to actually enforce a stronger alignment on u32, which in
> theory would not break anything.

It seems like an interesting compiler.

Does it also enforce 8 byte alignment to u8?
(that is, 7-byte padding for u8 ?)



>
> But in this precise case it does break something since it will cause
> "gaps" in the end result vmlinux binary segment. For this to work I
> think we really want to enforce a 4 bytes alignment on the section.


My best guess it, it was previously working for the kvm compiler
because include/linux/export.h previously used an inline assembler.

The kvm toolchain presumably gives natural alignment/padding
to '.long' assembly directive, but enforces 8-byte to u32.




-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-25 12:21       ` Yann Sionneau
  2022-08-25 12:41         ` Ard Biesheuvel
  2022-08-28 13:41         ` Masahiro Yamada
@ 2022-08-28 13:59         ` Masahiro Yamada
  2022-09-05 13:56           ` Yann Sionneau
  2 siblings, 1 reply; 18+ messages in thread
From: Masahiro Yamada @ 2022-08-28 13:59 UTC (permalink / raw)
  To: Yann Sionneau; +Cc: Ard Biesheuvel, Linux Kbuild mailing list, linux-arch

On Thu, Aug 25, 2022 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote:
>
> Hello Ard,
>
> On 25/08/2022 14:12, Ard Biesheuvel wrote:
> > On Thu, 25 Aug 2022 at 14:10, Yann Sionneau <ysionneau@kalray.eu> wrote:
> >> Forwarding also the actual patch to linux-kbuild and linux-arch
> >>
> >> -------- Forwarded Message --------
> >> Subject:        [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
> >> Date:   Wed, 17 Aug 2022 18:14:38 +0200
> >> From:   Yann Sionneau <ysionneau@kalray.eu>
> >> To:     linux-kernel@vger.kernel.org
> >> CC:     Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada
> >> <masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian
> >> Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>
> >>
> >>
> >>
> > What happened to the commit log?
>
> This is a forward of this thread: https://lkml.org/lkml/2022/8/17/868
>
> Either I did something wrong with my email agent or maybe the email
> containing the cover letter is taking some time to reach you?
>
> >
> >> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
> >> ---
> >> include/linux/export-internal.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/export-internal.h
> >> b/include/linux/export-internal.h
> >> index c2b1d4fd5987..d86bfbd7fa6d 100644
> >> --- a/include/linux/export-internal.h
> >> +++ b/include/linux/export-internal.h
> >> @@ -12,6 +12,6 @@
> >> /* __used is needed to keep __crc_* for LTO */
> >> #define SYMBOL_CRC(sym, crc, sec) \
> >> - u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> >> + u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4)
> > __aligned(4) is the default for u32 so this should not be needed.
>
> Well, I am not completely sure about that. See my cover letter, previous
> mechanism for symbol CRC was actually enforcing the section alignment to
> 4 bytes boundary as well.
>
> Also, I'm not sure it is forbidden for an architecture/compiler
> implementation to actually enforce a stronger alignment on u32, which in
> theory would not break anything.
>
> But in this precise case it does break something since it will cause
> "gaps" in the end result vmlinux binary segment. For this to work I
> think we really want to enforce a 4 bytes alignment on the section.



Please teach me a bit more about the kvm compiler.



How does it get access to an array of u32?

u32 foo[2] = { 1, 2 };


Does the compiler insert padding between each element
so that both of &foo[0] and &foo[1] are 8-byte aligned?

Or, no padding, and the address of &foo[1] is  8 n + 4?





-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-26 10:17             ` Ard Biesheuvel
@ 2022-08-28 14:05               ` Masahiro Yamada
  2022-09-05 15:26                 ` Yann Sionneau
  2022-09-26  8:48                 ` Yann Sionneau
  0 siblings, 2 replies; 18+ messages in thread
From: Masahiro Yamada @ 2022-08-28 14:05 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Geert Uytterhoeven, Yann Sionneau, Arnd Bergmann, linux-kbuild,
	Linux-Arch

On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Ard,
> >
> > On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
> > > > Well, I am not completely sure about that. See my cover letter, previous
> > > > mechanism for symbol CRC was actually enforcing the section alignment to
> > > > 4 bytes boundary as well.
> >
> > Yes, because else it may become 2-byte aligned on m68k.
> >
> > > > Also, I'm not sure it is forbidden for an architecture/compiler
> > > > implementation to actually enforce a stronger alignment on u32, which in
> > > > theory would not break anything.
> > > >
> > >
> > > u32 is a Linux type, and Linux expects natural alignment (and padding).
> >
> > Is it? You probably mean its alignment should not be larger than
> > 4 bytes? Less has been working since basically forever.
> >
>
> You are quite right. of course. And indeed, the issue here is padding
> not alignment.
>

I do not know if __align(4) should be used to avoid the padding issue.



Do you think it is a good idea to use an inline assembler,
as prior to 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b ?


This patch:

diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index c2b1d4fd5987..fb90f326b1b5 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -12,6 +12,9 @@

 /* __used is needed to keep __crc_* for LTO */
 #define SYMBOL_CRC(sym, crc, sec)   \
-       u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
+       asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
+           "__crc_" #sym ":"                                   "\n" \
+           ".long " #crc                                       "\n" \
+           ".previous"                                         "\n")

 #endif /* __LINUX_EXPORT_INTERNAL_H__ */







--
Best Regards

Masahiro Yamada

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-28 13:59         ` Masahiro Yamada
@ 2022-09-05 13:56           ` Yann Sionneau
  0 siblings, 0 replies; 18+ messages in thread
From: Yann Sionneau @ 2022-09-05 13:56 UTC (permalink / raw)
  To: Masahiro Yamada; +Cc: Ard Biesheuvel, Linux Kbuild mailing list, linux-arch

Hello Masahiro,

On 8/28/22 15:59, Masahiro Yamada wrote:
> On Thu, Aug 25, 2022 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote:
>> Hello Ard,
>>
>> On 25/08/2022 14:12, Ard Biesheuvel wrote:
>>> On Thu, 25 Aug 2022 at 14:10, Yann Sionneau <ysionneau@kalray.eu> wrote:
>>>> Forwarding also the actual patch to linux-kbuild and linux-arch
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject:        [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
>>>> Date:   Wed, 17 Aug 2022 18:14:38 +0200
>>>> From:   Yann Sionneau <ysionneau@kalray.eu>
>>>> To:     linux-kernel@vger.kernel.org
>>>> CC:     Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada
>>>> <masahiroy@kernel.org>, Jules Maselbas <jmaselbas@kalray.eu>, Julian
>>>> Vetter <jvetter@kalray.eu>, Yann Sionneau <ysionneau@kalray.eu>
>>>>
>>>>
>>>>
>>> What happened to the commit log?
>> This is a forward of this thread: https://lkml.org/lkml/2022/8/17/868
>>
>> Either I did something wrong with my email agent or maybe the email
>> containing the cover letter is taking some time to reach you?
>>
>>>> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
>>>> ---
>>>> include/linux/export-internal.h | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/linux/export-internal.h
>>>> b/include/linux/export-internal.h
>>>> index c2b1d4fd5987..d86bfbd7fa6d 100644
>>>> --- a/include/linux/export-internal.h
>>>> +++ b/include/linux/export-internal.h
>>>> @@ -12,6 +12,6 @@
>>>> /* __used is needed to keep __crc_* for LTO */
>>>> #define SYMBOL_CRC(sym, crc, sec) \
>>>> - u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
>>>> + u32 __section("___kcrctab" sec "+" #sym) __used __aligned(4)
>>> __aligned(4) is the default for u32 so this should not be needed.
>> Well, I am not completely sure about that. See my cover letter, previous
>> mechanism for symbol CRC was actually enforcing the section alignment to
>> 4 bytes boundary as well.
>>
>> Also, I'm not sure it is forbidden for an architecture/compiler
>> implementation to actually enforce a stronger alignment on u32, which in
>> theory would not break anything.
>>
>> But in this precise case it does break something since it will cause
>> "gaps" in the end result vmlinux binary segment. For this to work I
>> think we really want to enforce a 4 bytes alignment on the section.
>
>
> Please teach me a bit more about the kvm compiler.
>
>
>
> How does it get access to an array of u32?
>
> u32 foo[2] = { 1, 2 };
>
>
> Does the compiler insert padding between each element
> so that both of &foo[0] and &foo[1] are 8-byte aligned?
>
> Or, no padding, and the address of &foo[1] is  8 n + 4?

Here is what's happening: https://godbolt.org/z/Yz74W7jGY

unsignedintfoo[2] = { 1, 2};
intget_foo_sum(unsignedint*foo) {
returnfoo[0] + foo[1];
}
gets compiled to:
get_foo_sum:
lwz$r1=0[$r0]
;; # (end cycle 0)
lwz$r0=4[$r0]
;; # (end cycle 1)
addw$r0=$r1, $r0
ret
;; # (end cycle 4)
foo:
.long1
.long2
So it seems that no padding is inserted. Which looks sane ^^





^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-28 14:05               ` Masahiro Yamada
@ 2022-09-05 15:26                 ` Yann Sionneau
  2022-09-26  8:48                 ` Yann Sionneau
  1 sibling, 0 replies; 18+ messages in thread
From: Yann Sionneau @ 2022-09-05 15:26 UTC (permalink / raw)
  To: Masahiro Yamada, Ard Biesheuvel
  Cc: Geert Uytterhoeven, Arnd Bergmann, linux-kbuild, Linux-Arch

Hello Masahiro,

On 8/28/22 16:05, Masahiro Yamada wrote:
> On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Hi Ard,
>>>
>>> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>>>> On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
>>>>> Well, I am not completely sure about that. See my cover letter, previous
>>>>> mechanism for symbol CRC was actually enforcing the section alignment to
>>>>> 4 bytes boundary as well.
>>> Yes, because else it may become 2-byte aligned on m68k.
>>>
>>>>> Also, I'm not sure it is forbidden for an architecture/compiler
>>>>> implementation to actually enforce a stronger alignment on u32, which in
>>>>> theory would not break anything.
>>>>>
>>>> u32 is a Linux type, and Linux expects natural alignment (and padding).
>>> Is it? You probably mean its alignment should not be larger than
>>> 4 bytes? Less has been working since basically forever.
>>>
>> You are quite right. of course. And indeed, the issue here is padding
>> not alignment.
>>
> I do not know if __align(4) should be used to avoid the padding issue.
>
>
>
> Do you think it is a good idea to use an inline assembler,
> as prior to 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b ?
>
>
> This patch:
>
> diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
> index c2b1d4fd5987..fb90f326b1b5 100644
> --- a/include/linux/export-internal.h
> +++ b/include/linux/export-internal.h
> @@ -12,6 +12,9 @@
>
>   /* __used is needed to keep __crc_* for LTO */
>   #define SYMBOL_CRC(sym, crc, sec)   \
> -       u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> +       asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
> +           "__crc_" #sym ":"                                   "\n" \
> +           ".long " #crc                                       "\n" \
> +           ".previous"                                         "\n")
>
>   #endif /* __LINUX_EXPORT_INTERNAL_H__ */

I can confirm that this patch solves my kernel module CRC issues on kvx 
port.

Thanks,

-- 

Yann






^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-08-28 14:05               ` Masahiro Yamada
  2022-09-05 15:26                 ` Yann Sionneau
@ 2022-09-26  8:48                 ` Yann Sionneau
  2022-09-26  9:05                   ` Masahiro Yamada
  2022-09-26  9:05                   ` Ard Biesheuvel
  1 sibling, 2 replies; 18+ messages in thread
From: Yann Sionneau @ 2022-09-26  8:48 UTC (permalink / raw)
  To: Masahiro Yamada, Ard Biesheuvel
  Cc: Geert Uytterhoeven, Arnd Bergmann, linux-kbuild, Linux-Arch


On 8/28/22 16:05, Masahiro Yamada wrote:
> On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Hi Ard,
>>>
>>> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>>>> On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
>>>>> Well, I am not completely sure about that. See my cover letter, previous
>>>>> mechanism for symbol CRC was actually enforcing the section alignment to
>>>>> 4 bytes boundary as well.
>>> Yes, because else it may become 2-byte aligned on m68k.
>>>
>>>>> Also, I'm not sure it is forbidden for an architecture/compiler
>>>>> implementation to actually enforce a stronger alignment on u32, which in
>>>>> theory would not break anything.
>>>>>
>>>> u32 is a Linux type, and Linux expects natural alignment (and padding).
>>> Is it? You probably mean its alignment should not be larger than
>>> 4 bytes? Less has been working since basically forever.
>>>
>> You are quite right. of course. And indeed, the issue here is padding
>> not alignment.
>>
> I do not know if __align(4) should be used to avoid the padding issue.
>
>
>
> Do you think it is a good idea to use an inline assembler,
> as prior to 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b ?
>
>
> This patch:
>
> diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
> index c2b1d4fd5987..fb90f326b1b5 100644
> --- a/include/linux/export-internal.h
> +++ b/include/linux/export-internal.h
> @@ -12,6 +12,9 @@
>
>   /* __used is needed to keep __crc_* for LTO */
>   #define SYMBOL_CRC(sym, crc, sec)   \
> -       u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> +       asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
> +           "__crc_" #sym ":"                                   "\n" \
> +           ".long " #crc                                       "\n" \
> +           ".previous"                                         "\n")
>
>   #endif /* __LINUX_EXPORT_INTERNAL_H__ */

Ping on this topic, should we "fix our toolchain"?

Or should Linux code be modified to add either __align(4) or use the 
inline assembler? (I've tried your inline asm patch and it seems to fix 
the issue I'm having).

Or both?

Thanks,

Yann






^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-09-26  8:48                 ` Yann Sionneau
@ 2022-09-26  9:05                   ` Masahiro Yamada
  2022-09-26  9:11                     ` Ard Biesheuvel
  2022-09-26  9:05                   ` Ard Biesheuvel
  1 sibling, 1 reply; 18+ messages in thread
From: Masahiro Yamada @ 2022-09-26  9:05 UTC (permalink / raw)
  To: Yann Sionneau
  Cc: Ard Biesheuvel, Geert Uytterhoeven, Arnd Bergmann, linux-kbuild,
	Linux-Arch

On Mon, Sep 26, 2022 at 5:48 PM Yann Sionneau <ysionneau@kalray.eu> wrote:
>
>
> On 8/28/22 16:05, Masahiro Yamada wrote:
> > On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >> On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>> Hi Ard,
> >>>
> >>> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >>>> On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
> >>>>> Well, I am not completely sure about that. See my cover letter, previous
> >>>>> mechanism for symbol CRC was actually enforcing the section alignment to
> >>>>> 4 bytes boundary as well.
> >>> Yes, because else it may become 2-byte aligned on m68k.
> >>>
> >>>>> Also, I'm not sure it is forbidden for an architecture/compiler
> >>>>> implementation to actually enforce a stronger alignment on u32, which in
> >>>>> theory would not break anything.
> >>>>>
> >>>> u32 is a Linux type, and Linux expects natural alignment (and padding).
> >>> Is it? You probably mean its alignment should not be larger than
> >>> 4 bytes? Less has been working since basically forever.
> >>>
> >> You are quite right. of course. And indeed, the issue here is padding
> >> not alignment.
> >>
> > I do not know if __align(4) should be used to avoid the padding issue.
> >
> >
> >
> > Do you think it is a good idea to use an inline assembler,
> > as prior to 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b ?
> >
> >
> > This patch:
> >
> > diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
> > index c2b1d4fd5987..fb90f326b1b5 100644
> > --- a/include/linux/export-internal.h
> > +++ b/include/linux/export-internal.h
> > @@ -12,6 +12,9 @@
> >
> >   /* __used is needed to keep __crc_* for LTO */
> >   #define SYMBOL_CRC(sym, crc, sec)   \
> > -       u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> > +       asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
> > +           "__crc_" #sym ":"                                   "\n" \
> > +           ".long " #crc                                       "\n" \
> > +           ".previous"                                         "\n")
> >
> >   #endif /* __LINUX_EXPORT_INTERNAL_H__ */
>
> Ping on this topic, should we "fix our toolchain"?
>
> Or should Linux code be modified to add either __align(4) or use the
> inline assembler? (I've tried your inline asm patch and it seems to fix
> the issue I'm having).
>
> Or both?
>
> Thanks,
>
> Yann
>
>
>
>
>


I queued up the patch.
You can see it in linux-next.


Once it lands in the mainline,
it will be back-ported.






masahiro@zoe:~/ref/linux-next$ git log -1 next-20220923 --
include/linux/export-internal.h
commit 60ecfddd7a092f9cbd2398dbc55da3abbb803ff0
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri Sep 16 15:29:53 2022 +0900

    linux/export: use inline assembler to populate symbol CRCs

    Since commit 7b4537199a4a ("kbuild: link symbol CRCs at final link,
    removing CONFIG_MODULE_REL_CRCS"), the module versioning on the
    (non-upstreamed-yet) kvx Linux port is broken due to unexpected padding
    for __crc_* symbols. The kvx GCC adds padding so u32 gets 8-byte
    alignment instead of 4.

    I do not know if this happens for upstream architectures in general,
    but any compiler has the freedom to insert padding for faster access.

    Use the inline assembler to directly specify the wanted data layout.
    This is how we previously did before the breakage.

    Link: https://lore.kernel.org/lkml/20220817161438.32039-1-ysionneau@kalray.eu/
    Link: https://lore.kernel.org/linux-kbuild/31ce5305-a76b-13d7-ea55-afca82c46cf2@kalray.eu/
    Fixes: 7b4537199a4a ("kbuild: link symbol CRCs at final link,
removing CONFIG_MODULE_REL_CRCS")
    Reported-by: Yann Sionneau <ysionneau@kalray.eu>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Tested-by: Yann Sionneau <ysionneau@kalray.eu>







-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-09-26  8:48                 ` Yann Sionneau
  2022-09-26  9:05                   ` Masahiro Yamada
@ 2022-09-26  9:05                   ` Ard Biesheuvel
  1 sibling, 0 replies; 18+ messages in thread
From: Ard Biesheuvel @ 2022-09-26  9:05 UTC (permalink / raw)
  To: Yann Sionneau
  Cc: Masahiro Yamada, Geert Uytterhoeven, Arnd Bergmann, linux-kbuild,
	Linux-Arch

On Mon, 26 Sept 2022 at 10:48, Yann Sionneau <ysionneau@kalray.eu> wrote:
>
>
> On 8/28/22 16:05, Masahiro Yamada wrote:
> > On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >> On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>> Hi Ard,
> >>>
> >>> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >>>> On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
> >>>>> Well, I am not completely sure about that. See my cover letter, previous
> >>>>> mechanism for symbol CRC was actually enforcing the section alignment to
> >>>>> 4 bytes boundary as well.
> >>> Yes, because else it may become 2-byte aligned on m68k.
> >>>
> >>>>> Also, I'm not sure it is forbidden for an architecture/compiler
> >>>>> implementation to actually enforce a stronger alignment on u32, which in
> >>>>> theory would not break anything.
> >>>>>
> >>>> u32 is a Linux type, and Linux expects natural alignment (and padding).
> >>> Is it? You probably mean its alignment should not be larger than
> >>> 4 bytes? Less has been working since basically forever.
> >>>
> >> You are quite right. of course. And indeed, the issue here is padding
> >> not alignment.
> >>
> > I do not know if __align(4) should be used to avoid the padding issue.
> >
> >
> >
> > Do you think it is a good idea to use an inline assembler,
> > as prior to 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b ?
> >
> >
> > This patch:
> >
> > diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
> > index c2b1d4fd5987..fb90f326b1b5 100644
> > --- a/include/linux/export-internal.h
> > +++ b/include/linux/export-internal.h
> > @@ -12,6 +12,9 @@
> >
> >   /* __used is needed to keep __crc_* for LTO */
> >   #define SYMBOL_CRC(sym, crc, sec)   \
> > -       u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> > +       asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
> > +           "__crc_" #sym ":"                                   "\n" \
> > +           ".long " #crc                                       "\n" \
> > +           ".previous"                                         "\n")
> >
> >   #endif /* __LINUX_EXPORT_INTERNAL_H__ */
>
> Ping on this topic, should we "fix our toolchain"?
>
> Or should Linux code be modified to add either __align(4) or use the
> inline assembler? (I've tried your inline asm patch and it seems to fix
> the issue I'm having).
>
> Or both?
>

There are other cases where we rely on sections containing arrays of
u32 to be concatenated without gaps. If you would ever want to enable
HAVE_ARCH_PREL32_RELOCATIONS for your architecture (in order to save
some space in the binary wasted on absolute addresses or RELA
relocations) you'd run into the same issue afaict. So I'd recommend
fixing this in your compiler or linker asap.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment
  2022-09-26  9:05                   ` Masahiro Yamada
@ 2022-09-26  9:11                     ` Ard Biesheuvel
  0 siblings, 0 replies; 18+ messages in thread
From: Ard Biesheuvel @ 2022-09-26  9:11 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Yann Sionneau, Geert Uytterhoeven, Arnd Bergmann, linux-kbuild,
	Linux-Arch

On Mon, 26 Sept 2022 at 11:06, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Mon, Sep 26, 2022 at 5:48 PM Yann Sionneau <ysionneau@kalray.eu> wrote:
> >
> >
> > On 8/28/22 16:05, Masahiro Yamada wrote:
> > > On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >> On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >>> Hi Ard,
> > >>>
> > >>> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >>>> On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@kalray.eu> wrote:
> > >>>>> Well, I am not completely sure about that. See my cover letter, previous
> > >>>>> mechanism for symbol CRC was actually enforcing the section alignment to
> > >>>>> 4 bytes boundary as well.
> > >>> Yes, because else it may become 2-byte aligned on m68k.
> > >>>
> > >>>>> Also, I'm not sure it is forbidden for an architecture/compiler
> > >>>>> implementation to actually enforce a stronger alignment on u32, which in
> > >>>>> theory would not break anything.
> > >>>>>
> > >>>> u32 is a Linux type, and Linux expects natural alignment (and padding).
> > >>> Is it? You probably mean its alignment should not be larger than
> > >>> 4 bytes? Less has been working since basically forever.
> > >>>
> > >> You are quite right. of course. And indeed, the issue here is padding
> > >> not alignment.
> > >>
> > > I do not know if __align(4) should be used to avoid the padding issue.
> > >
> > >
> > >
> > > Do you think it is a good idea to use an inline assembler,
> > > as prior to 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b ?
> > >
> > >
> > > This patch:
> > >
> > > diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
> > > index c2b1d4fd5987..fb90f326b1b5 100644
> > > --- a/include/linux/export-internal.h
> > > +++ b/include/linux/export-internal.h
> > > @@ -12,6 +12,9 @@
> > >
> > >   /* __used is needed to keep __crc_* for LTO */
> > >   #define SYMBOL_CRC(sym, crc, sec)   \
> > > -       u32 __section("___kcrctab" sec "+" #sym) __used __crc_##sym = crc
> > > +       asm(".section \"___kcrctab" sec "+" #sym "\",\"a\""     "\n" \
> > > +           "__crc_" #sym ":"                                   "\n" \
> > > +           ".long " #crc                                       "\n" \
> > > +           ".previous"                                         "\n")
> > >
> > >   #endif /* __LINUX_EXPORT_INTERNAL_H__ */
> >
> > Ping on this topic, should we "fix our toolchain"?
> >
> > Or should Linux code be modified to add either __align(4) or use the
> > inline assembler? (I've tried your inline asm patch and it seems to fix
> > the issue I'm having).
> >
> > Or both?
> >
> > Thanks,
> >
> > Yann
> >
> >
> >
> >
> >
>
>
> I queued up the patch.
> You can see it in linux-next.
>
>
> Once it lands in the mainline,
> it will be back-ported.
>
>
>
>
>
>
> masahiro@zoe:~/ref/linux-next$ git log -1 next-20220923 --
> include/linux/export-internal.h
> commit 60ecfddd7a092f9cbd2398dbc55da3abbb803ff0
> Author: Masahiro Yamada <masahiroy@kernel.org>
> Date:   Fri Sep 16 15:29:53 2022 +0900
>
>     linux/export: use inline assembler to populate symbol CRCs
>
>     Since commit 7b4537199a4a ("kbuild: link symbol CRCs at final link,
>     removing CONFIG_MODULE_REL_CRCS"), the module versioning on the
>     (non-upstreamed-yet) kvx Linux port is broken due to unexpected padding
>     for __crc_* symbols. The kvx GCC adds padding so u32 gets 8-byte
>     alignment instead of 4.
>
>     I do not know if this happens for upstream architectures in general,
>     but any compiler has the freedom to insert padding for faster access.
>
>     Use the inline assembler to directly specify the wanted data layout.
>     This is how we previously did before the breakage.
>
>     Link: https://lore.kernel.org/lkml/20220817161438.32039-1-ysionneau@kalray.eu/
>     Link: https://lore.kernel.org/linux-kbuild/31ce5305-a76b-13d7-ea55-afca82c46cf2@kalray.eu/
>     Fixes: 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> removing CONFIG_MODULE_REL_CRCS")
>     Reported-by: Yann Sionneau <ysionneau@kalray.eu>
>     Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>     Tested-by: Yann Sionneau <ysionneau@kalray.eu>
>

I don't think we should merge this. kvm is an experimental out of tree
port, and everywhere else, we already rely heavily on array sections
constructed by the linker where it just concatenate sections from the
input objects, and assumes there will be no padding.

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-09-26  9:11 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-17 16:14 [RFC PATCH 0/1] Fix __kcrctab+* sections alignment Yann Sionneau
2022-08-17 16:14 ` [RFC PATCH 1/1] " Yann Sionneau
2022-08-25 12:03   ` Fwd: " Yann Sionneau
2022-08-25 12:12     ` Ard Biesheuvel
2022-08-25 12:21       ` Yann Sionneau
2022-08-25 12:41         ` Ard Biesheuvel
2022-08-25 18:01           ` Geert Uytterhoeven
2022-08-26 10:17             ` Ard Biesheuvel
2022-08-28 14:05               ` Masahiro Yamada
2022-09-05 15:26                 ` Yann Sionneau
2022-09-26  8:48                 ` Yann Sionneau
2022-09-26  9:05                   ` Masahiro Yamada
2022-09-26  9:11                     ` Ard Biesheuvel
2022-09-26  9:05                   ` Ard Biesheuvel
2022-08-28 13:41         ` Masahiro Yamada
2022-08-28 13:59         ` Masahiro Yamada
2022-09-05 13:56           ` Yann Sionneau
2022-08-25 12:03 ` Fwd: [RFC PATCH 0/1] " Yann Sionneau

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.