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__ */
--
Best Regards
Masahiro Yamada
