Re: [RFC PATCH 1/1] Fix __kcrctab+* sections alignment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 8/28/22 16:05, Masahiro Yamada wrote:
On Fri, Aug 26, 2022 at 7:17 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
Hi Ard,

On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@xxxxxxxxx> 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








[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux