* Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
[not found] ` <20220513113930.10488-3-masahiroy@kernel.org>
@ 2022-08-20 10:02 ` Christophe Leroy
2022-08-20 12:05 ` Sedat Dilek
2022-08-20 12:51 ` Masahiro Yamada
0 siblings, 2 replies; 7+ messages in thread
From: Christophe Leroy @ 2022-08-20 10:02 UTC (permalink / raw)
To: Masahiro Yamada, linux-kbuild@vger.kernel.org
Cc: Nicolas Schier, Peter Zijlstra, llvm@lists.linux.dev,
Nick Desaulniers, linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
Hi,
Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> as a placeholder.
>
> Genksyms writes the version CRCs into the linker script, which will be
> used for filling the __crc_* symbols. The linker script format depends
> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> to the reference of CRC.
>
> It is time to get rid of this complexity.
>
> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> it can generate C code that will be linked to the vmlinux or modules.
>
> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> symbols exported by vmlinux. It is compiled and linked to vmlinux in
> scripts/link-vmlinux.sh.
>
> Put the CRCs of symbols exported by modules into the existing *.mod.c
> files. No additional build step is needed for modules. As before,
> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>
> No linker magic is used here. The new C implementation works in the
> same way, whether CONFIG_RELOCATABLE is enabled or not.
> CONFIG_MODULE_REL_CRCS is no longer needed.
>
> Previously, Kbuild invoked additional $(LD) to update the CRCs in
> objects, but this step is unneeded too.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> Tested-by: Nicolas Schier <nicolas@fjasle.eu>
> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Problem with v6.0-rc1
Problem with v5.19
No problem with v5.18
Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
removing CONFIG_MODULE_REL_CRCS")
The above patch leads to the following problem building
mpc85xx_defconfig + CONFIG_RELOCATABLE
LD vmlinux
SYSMAP System.map
SORTTAB vmlinux
CHKREL vmlinux
WARNING: 451 bad relocations
c0b0f26d R_PPC_UADDR32 .head.text-0x3ff9f2bc
c0b0f271 R_PPC_UADDR32 .head.text-0x3ffac300
c0b0f275 R_PPC_UADDR32 .head.text-0x3ffb0bdc
c0b0f279 R_PPC_UADDR32 .head.text-0x3fe1e080
c0b0f27d R_PPC_UADDR32 .head.text-0x3fe1df4c
c0b0f281 R_PPC_UADDR32 .head.text-0x3fe21514
c0b0f285 R_PPC_UADDR32 .head.text-0x3fe211c0
c0b0f289 R_PPC_UADDR32 .head.text-0x3ffabda0
c0b0f28d R_PPC_UADDR32 .head.text-0x3fe21258
c0b0f291 R_PPC_UADDR32 .head.text-0x3fe074d0
c0b0f295 R_PPC_UADDR32 .head.text-0x3fe07ad4
c0b0f299 R_PPC_UADDR32 .head.text-0x3fe13470
c0b0f29d R_PPC_UADDR32 .head.text-0x3fe22700
c0b0f2a1 R_PPC_UADDR32 .head.text-0x3ff4b8e0
c0b0f2a5 R_PPC_UADDR32 .head.text-0x3fe08320
c0b0f2a9 R_PPC_UADDR32 .head.text-0x3fe220dc
c0b0f2ad R_PPC_UADDR32 .head.text-0x3fe21da0
c0b0f2b1 R_PPC_UADDR32 .head.text-0x3ff89dc0
c0b0f2b5 R_PPC_UADDR32 .head.text-0x3fe16524
c0b0f2b9 R_PPC_UADDR32 .head.text-0x3fe1ef74
c0b0f2bd R_PPC_UADDR32 .head.text-0x3ff98b84
c0b0f2c1 R_PPC_UADDR32 .head.text-0x3fdef9a0
c0b0f2c5 R_PPC_UADDR32 .head.text-0x3fdf21ac
c0b0f2c9 R_PPC_UADDR32 .head.text-0x3ff993c4
...
c0b0f969 R_PPC_UADDR32 .head.text-0x3ff89dc0
c0b0f96d R_PPC_UADDR32 .head.text-0x3fe9ad40
c0b0f971 R_PPC_UADDR32 .head.text-0x3ff2eb00
c0b0f975 R_PPC_UADDR32 .head.text-0x3ff89dc0
And boot fails:
Run /init as init process
kernel tried to execute user page (0) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MPC8544 DS
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc1-00054-g7b4537199a4a #1523
NIP: 00000000 LR: c00150e4 CTR: 00000000
REGS: c3091e10 TRAP: 0400 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
MSR: 00009000 <EE,ME> CR: 88000422 XER: 20000000
GPR00: 00004000 c3091f00 c30c8000 00000000 00000013 b7bb9f4c b7bd8f60
bfee6650
GPR08: 00000054 00000000 c0b0f26d 00000000 c13b0000 00000000 bfee6668
00000000
GPR16: 84e08000 00000000 08000000 00000064 00000000 00102000 00000001
00000001
GPR24: 00000001 00000001 b7b9c7d0 10000034 00000009 b7bd8f38 b7bd9854
b7bd8688
NIP [00000000] 0x0
LR [c00150e4] ret_from_syscall+0x0/0x28
Call Trace:
[c3091f00] [c0000af0] InstructionStorage+0x150/0x160 (unreliable)
--- interrupt: c00 at 0xb7bb28e8
NIP: b7bb28e8 LR: b7bb1384 CTR: b7bb1218
REGS: c3091f10 TRAP: 0c00 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
MSR: 0002d000 <CE,EE,PR,ME> CR: 28000422 XER: 20000000
GPR00: 0000002d bfee61f0 00000000 00000000 00000013 b7bb9f4c b7bd8f60
bfee6650
GPR08: 00000054 00000020 bfee6648 00000000 00000001 00000000 bfee6668
00000000
GPR16: 84e08000 00000000 08000000 00000064 00000000 00102000 00000001
00000001
GPR24: 00000001 00000001 b7b9c7d0 10000034 00000009 b7bd8f38 b7bd9854
b7bd8688
NIP [b7bb28e8] 0xb7bb28e8
LR [b7bb1384] 0xb7bb1384
--- interrupt: c00
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Christophe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
2022-08-20 10:02 ` Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS) Christophe Leroy
@ 2022-08-20 12:05 ` Sedat Dilek
2022-08-20 14:10 ` Christophe Leroy
2022-08-20 12:51 ` Masahiro Yamada
1 sibling, 1 reply; 7+ messages in thread
From: Sedat Dilek @ 2022-08-20 12:05 UTC (permalink / raw)
To: Christophe Leroy
Cc: Nicolas Schier, linux-kbuild@vger.kernel.org, Peter Zijlstra,
Masahiro Yamada, llvm@lists.linux.dev, Nick Desaulniers,
linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
On Sat, Aug 20, 2022 at 12:04 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> Hi,
>
> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> > include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> > as a placeholder.
> >
> > Genksyms writes the version CRCs into the linker script, which will be
> > used for filling the __crc_* symbols. The linker script format depends
> > on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> > to the reference of CRC.
> >
> > It is time to get rid of this complexity.
> >
> > Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> > it can generate C code that will be linked to the vmlinux or modules.
> >
> > Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> > symbols exported by vmlinux. It is compiled and linked to vmlinux in
> > scripts/link-vmlinux.sh.
> >
> > Put the CRCs of symbols exported by modules into the existing *.mod.c
> > files. No additional build step is needed for modules. As before,
> > *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
> >
> > No linker magic is used here. The new C implementation works in the
> > same way, whether CONFIG_RELOCATABLE is enabled or not.
> > CONFIG_MODULE_REL_CRCS is no longer needed.
> >
> > Previously, Kbuild invoked additional $(LD) to update the CRCs in
> > objects, but this step is unneeded too.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > Tested-by: Nathan Chancellor <nathan@kernel.org>
> > Tested-by: Nicolas Schier <nicolas@fjasle.eu>
> > Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
>
> Problem with v6.0-rc1
> Problem with v5.19
> No problem with v5.18
>
> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> removing CONFIG_MODULE_REL_CRCS")
>
What you are looking for is...
commit 7d13fd96df875a9d786ee6dcc8fec460d35d4b12
("modpost: fix module versioning when a symbol lacks valid CRC")
It's pending in kbuild.git#fixes.
-Sedat-
[1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes&id=7d13fd96df875a9d786ee6dcc8fec460d35d4b12
[2] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=fixes
> The above patch leads to the following problem building
> mpc85xx_defconfig + CONFIG_RELOCATABLE
>
> LD vmlinux
> SYSMAP System.map
> SORTTAB vmlinux
> CHKREL vmlinux
> WARNING: 451 bad relocations
> c0b0f26d R_PPC_UADDR32 .head.text-0x3ff9f2bc
> c0b0f271 R_PPC_UADDR32 .head.text-0x3ffac300
> c0b0f275 R_PPC_UADDR32 .head.text-0x3ffb0bdc
> c0b0f279 R_PPC_UADDR32 .head.text-0x3fe1e080
> c0b0f27d R_PPC_UADDR32 .head.text-0x3fe1df4c
> c0b0f281 R_PPC_UADDR32 .head.text-0x3fe21514
> c0b0f285 R_PPC_UADDR32 .head.text-0x3fe211c0
> c0b0f289 R_PPC_UADDR32 .head.text-0x3ffabda0
> c0b0f28d R_PPC_UADDR32 .head.text-0x3fe21258
> c0b0f291 R_PPC_UADDR32 .head.text-0x3fe074d0
> c0b0f295 R_PPC_UADDR32 .head.text-0x3fe07ad4
> c0b0f299 R_PPC_UADDR32 .head.text-0x3fe13470
> c0b0f29d R_PPC_UADDR32 .head.text-0x3fe22700
> c0b0f2a1 R_PPC_UADDR32 .head.text-0x3ff4b8e0
> c0b0f2a5 R_PPC_UADDR32 .head.text-0x3fe08320
> c0b0f2a9 R_PPC_UADDR32 .head.text-0x3fe220dc
> c0b0f2ad R_PPC_UADDR32 .head.text-0x3fe21da0
> c0b0f2b1 R_PPC_UADDR32 .head.text-0x3ff89dc0
> c0b0f2b5 R_PPC_UADDR32 .head.text-0x3fe16524
> c0b0f2b9 R_PPC_UADDR32 .head.text-0x3fe1ef74
> c0b0f2bd R_PPC_UADDR32 .head.text-0x3ff98b84
> c0b0f2c1 R_PPC_UADDR32 .head.text-0x3fdef9a0
> c0b0f2c5 R_PPC_UADDR32 .head.text-0x3fdf21ac
> c0b0f2c9 R_PPC_UADDR32 .head.text-0x3ff993c4
> ...
> c0b0f969 R_PPC_UADDR32 .head.text-0x3ff89dc0
> c0b0f96d R_PPC_UADDR32 .head.text-0x3fe9ad40
> c0b0f971 R_PPC_UADDR32 .head.text-0x3ff2eb00
> c0b0f975 R_PPC_UADDR32 .head.text-0x3ff89dc0
>
> And boot fails:
>
> Run /init as init process
> kernel tried to execute user page (0) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch (NULL pointer?)
> Faulting instruction address: 0x00000000
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K MPC8544 DS
> Modules linked in:
> CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc1-00054-g7b4537199a4a #1523
> NIP: 00000000 LR: c00150e4 CTR: 00000000
> REGS: c3091e10 TRAP: 0400 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
> MSR: 00009000 <EE,ME> CR: 88000422 XER: 20000000
>
> GPR00: 00004000 c3091f00 c30c8000 00000000 00000013 b7bb9f4c b7bd8f60
> bfee6650
> GPR08: 00000054 00000000 c0b0f26d 00000000 c13b0000 00000000 bfee6668
> 00000000
> GPR16: 84e08000 00000000 08000000 00000064 00000000 00102000 00000001
> 00000001
> GPR24: 00000001 00000001 b7b9c7d0 10000034 00000009 b7bd8f38 b7bd9854
> b7bd8688
> NIP [00000000] 0x0
> LR [c00150e4] ret_from_syscall+0x0/0x28
> Call Trace:
> [c3091f00] [c0000af0] InstructionStorage+0x150/0x160 (unreliable)
> --- interrupt: c00 at 0xb7bb28e8
> NIP: b7bb28e8 LR: b7bb1384 CTR: b7bb1218
> REGS: c3091f10 TRAP: 0c00 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
> MSR: 0002d000 <CE,EE,PR,ME> CR: 28000422 XER: 20000000
>
> GPR00: 0000002d bfee61f0 00000000 00000000 00000013 b7bb9f4c b7bd8f60
> bfee6650
> GPR08: 00000054 00000020 bfee6648 00000000 00000001 00000000 bfee6668
> 00000000
> GPR16: 84e08000 00000000 08000000 00000064 00000000 00102000 00000001
> 00000001
> GPR24: 00000001 00000001 b7b9c7d0 10000034 00000009 b7bd8f38 b7bd9854
> b7bd8688
> NIP [b7bb28e8] 0xb7bb28e8
> LR [b7bb1384] 0xb7bb1384
> --- interrupt: c00
> Instruction dump:
> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> ---[ end trace 0000000000000000 ]---
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
>
>
> Christophe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
2022-08-20 10:02 ` Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS) Christophe Leroy
2022-08-20 12:05 ` Sedat Dilek
@ 2022-08-20 12:51 ` Masahiro Yamada
2022-08-20 14:15 ` Christophe Leroy
1 sibling, 1 reply; 7+ messages in thread
From: Masahiro Yamada @ 2022-08-20 12:51 UTC (permalink / raw)
To: Christophe Leroy
Cc: Nicolas Schier, linux-kbuild@vger.kernel.org, Peter Zijlstra,
llvm@lists.linux.dev, Nick Desaulniers,
linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> Hi,
>
> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> > include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> > as a placeholder.
> >
> > Genksyms writes the version CRCs into the linker script, which will be
> > used for filling the __crc_* symbols. The linker script format depends
> > on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> > to the reference of CRC.
> >
> > It is time to get rid of this complexity.
> >
> > Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> > it can generate C code that will be linked to the vmlinux or modules.
> >
> > Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> > symbols exported by vmlinux. It is compiled and linked to vmlinux in
> > scripts/link-vmlinux.sh.
> >
> > Put the CRCs of symbols exported by modules into the existing *.mod.c
> > files. No additional build step is needed for modules. As before,
> > *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
> >
> > No linker magic is used here. The new C implementation works in the
> > same way, whether CONFIG_RELOCATABLE is enabled or not.
> > CONFIG_MODULE_REL_CRCS is no longer needed.
> >
> > Previously, Kbuild invoked additional $(LD) to update the CRCs in
> > objects, but this step is unneeded too.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > Tested-by: Nathan Chancellor <nathan@kernel.org>
> > Tested-by: Nicolas Schier <nicolas@fjasle.eu>
> > Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
>
> Problem with v6.0-rc1
> Problem with v5.19
> No problem with v5.18
>
> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> removing CONFIG_MODULE_REL_CRCS")
>
> The above patch leads to the following problem building
> mpc85xx_defconfig + CONFIG_RELOCATABLE
Is this because the relocation implementation on ppc is incomplete?
(and is it the reason why relock_check.sh exists?)
arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
2022-08-20 12:05 ` Sedat Dilek
@ 2022-08-20 14:10 ` Christophe Leroy
0 siblings, 0 replies; 7+ messages in thread
From: Christophe Leroy @ 2022-08-20 14:10 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: Nicolas Schier, linux-kbuild@vger.kernel.org, Peter Zijlstra,
Masahiro Yamada, llvm@lists.linux.dev, Nick Desaulniers,
linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
Le 20/08/2022 à 14:05, Sedat Dilek a écrit :
> On Sat, Aug 20, 2022 at 12:04 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> Hi,
>>
>> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
>>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
>>> as a placeholder.
>>>
>>> Genksyms writes the version CRCs into the linker script, which will be
>>> used for filling the __crc_* symbols. The linker script format depends
>>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
>>> to the reference of CRC.
>>>
>>> It is time to get rid of this complexity.
>>>
>>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
>>> it can generate C code that will be linked to the vmlinux or modules.
>>>
>>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
>>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
>>> scripts/link-vmlinux.sh.
>>>
>>> Put the CRCs of symbols exported by modules into the existing *.mod.c
>>> files. No additional build step is needed for modules. As before,
>>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>>>
>>> No linker magic is used here. The new C implementation works in the
>>> same way, whether CONFIG_RELOCATABLE is enabled or not.
>>> CONFIG_MODULE_REL_CRCS is no longer needed.
>>>
>>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
>>> objects, but this step is unneeded too.
>>>
>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>>> Tested-by: Nathan Chancellor <nathan@kernel.org>
>>> Tested-by: Nicolas Schier <nicolas@fjasle.eu>
>>> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
>>
>> Problem with v6.0-rc1
>> Problem with v5.19
>> No problem with v5.18
>>
>> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
>> removing CONFIG_MODULE_REL_CRCS")
>>
>
> What you are looking for is...
>
> commit 7d13fd96df875a9d786ee6dcc8fec460d35d4b12
> ("modpost: fix module versioning when a symbol lacks valid CRC")
>
> It's pending in kbuild.git#fixes.
>
> -Sedat-
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes&id=7d13fd96df875a9d786ee6dcc8fec460d35d4b12
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=fixes
>
That patch doesn't fix the problem.
Christophe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
2022-08-20 12:51 ` Masahiro Yamada
@ 2022-08-20 14:15 ` Christophe Leroy
2022-08-20 17:01 ` Masahiro Yamada
0 siblings, 1 reply; 7+ messages in thread
From: Christophe Leroy @ 2022-08-20 14:15 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Nicolas Schier, linux-kbuild@vger.kernel.org, Peter Zijlstra,
llvm@lists.linux.dev, Nick Desaulniers,
linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
Le 20/08/2022 à 14:51, Masahiro Yamada a écrit :
> On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> Hi,
>>
>> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
>>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
>>> as a placeholder.
>>>
>>> Genksyms writes the version CRCs into the linker script, which will be
>>> used for filling the __crc_* symbols. The linker script format depends
>>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
>>> to the reference of CRC.
>>>
>>> It is time to get rid of this complexity.
>>>
>>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
>>> it can generate C code that will be linked to the vmlinux or modules.
>>>
>>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
>>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
>>> scripts/link-vmlinux.sh.
>>>
>>> Put the CRCs of symbols exported by modules into the existing *.mod.c
>>> files. No additional build step is needed for modules. As before,
>>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>>>
>>> No linker magic is used here. The new C implementation works in the
>>> same way, whether CONFIG_RELOCATABLE is enabled or not.
>>> CONFIG_MODULE_REL_CRCS is no longer needed.
>>>
>>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
>>> objects, but this step is unneeded too.
>>>
>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>>> Tested-by: Nathan Chancellor <nathan@kernel.org>
>>> Tested-by: Nicolas Schier <nicolas@fjasle.eu>
>>> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
>>
>> Problem with v6.0-rc1
>> Problem with v5.19
>> No problem with v5.18
>>
>> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
>> removing CONFIG_MODULE_REL_CRCS")
>>
>> The above patch leads to the following problem building
>> mpc85xx_defconfig + CONFIG_RELOCATABLE
>
>
>
> Is this because the relocation implementation on ppc is incomplete?
> (and is it the reason why relock_check.sh exists?)
>
> arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
>
>
Might be the reason.
Is it expected that your patch adds an unsupported relocation ?
Why was that relocation type unneeded before ?
Thanks
Christophe
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
2022-08-20 14:15 ` Christophe Leroy
@ 2022-08-20 17:01 ` Masahiro Yamada
2022-08-20 17:51 ` Christophe Leroy
0 siblings, 1 reply; 7+ messages in thread
From: Masahiro Yamada @ 2022-08-20 17:01 UTC (permalink / raw)
To: Christophe Leroy
Cc: Nicolas Schier, linux-kbuild@vger.kernel.org, Peter Zijlstra,
llvm@lists.linux.dev, Nick Desaulniers,
linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
On Sat, Aug 20, 2022 at 11:15 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 20/08/2022 à 14:51, Masahiro Yamada a écrit :
> > On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >> Hi,
> >>
> >> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> >>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> >>> as a placeholder.
> >>>
> >>> Genksyms writes the version CRCs into the linker script, which will be
> >>> used for filling the __crc_* symbols. The linker script format depends
> >>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> >>> to the reference of CRC.
> >>>
> >>> It is time to get rid of this complexity.
> >>>
> >>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> >>> it can generate C code that will be linked to the vmlinux or modules.
> >>>
> >>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> >>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
> >>> scripts/link-vmlinux.sh.
> >>>
> >>> Put the CRCs of symbols exported by modules into the existing *.mod.c
> >>> files. No additional build step is needed for modules. As before,
> >>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
> >>>
> >>> No linker magic is used here. The new C implementation works in the
> >>> same way, whether CONFIG_RELOCATABLE is enabled or not.
> >>> CONFIG_MODULE_REL_CRCS is no longer needed.
> >>>
> >>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
> >>> objects, but this step is unneeded too.
> >>>
> >>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> >>> Tested-by: Nathan Chancellor <nathan@kernel.org>
> >>> Tested-by: Nicolas Schier <nicolas@fjasle.eu>
> >>> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
> >>
> >> Problem with v6.0-rc1
> >> Problem with v5.19
> >> No problem with v5.18
> >>
> >> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> >> removing CONFIG_MODULE_REL_CRCS")
> >>
> >> The above patch leads to the following problem building
> >> mpc85xx_defconfig + CONFIG_RELOCATABLE
> >
> >
> >
> > Is this because the relocation implementation on ppc is incomplete?
> > (and is it the reason why relock_check.sh exists?)
> >
> > arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
> >
> >
>
> Might be the reason.
>
> Is it expected that your patch adds an unsupported relocation ?
>
> Why was that relocation type unneeded before ?
>
> Thanks
> Christophe
I posted a patch (although I believe my commit is innocent).
https://lore.kernel.org/lkml/20220820165129.1147589-1-masahiroy@kernel.org/T/#u
The relocs_check.sh warnings are gone.
Please do a boot test.
Thanks.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
2022-08-20 17:01 ` Masahiro Yamada
@ 2022-08-20 17:51 ` Christophe Leroy
0 siblings, 0 replies; 7+ messages in thread
From: Christophe Leroy @ 2022-08-20 17:51 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Nicolas Schier, linux-kbuild@vger.kernel.org, Peter Zijlstra,
llvm@lists.linux.dev, Nick Desaulniers,
linux-kernel@vger.kernel.org, Nathan Chancellor,
Kirill A . Shutemov, Sami Tolvanen, linuxppc-dev@lists.ozlabs.org,
Ard Biesheuvel, linux-modules@vger.kernel.org
Le 20/08/2022 à 19:01, Masahiro Yamada a écrit :
> On Sat, Aug 20, 2022 at 11:15 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 20/08/2022 à 14:51, Masahiro Yamada a écrit :
>>> On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
>>> <christophe.leroy@csgroup.eu> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
>>>>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
>>>>> as a placeholder.
>>>>>
>>>>> Genksyms writes the version CRCs into the linker script, which will be
>>>>> used for filling the __crc_* symbols. The linker script format depends
>>>>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
>>>>> to the reference of CRC.
>>>>>
>>>>> It is time to get rid of this complexity.
>>>>>
>>>>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
>>>>> it can generate C code that will be linked to the vmlinux or modules.
>>>>>
>>>>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
>>>>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
>>>>> scripts/link-vmlinux.sh.
>>>>>
>>>>> Put the CRCs of symbols exported by modules into the existing *.mod.c
>>>>> files. No additional build step is needed for modules. As before,
>>>>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>>>>>
>>>>> No linker magic is used here. The new C implementation works in the
>>>>> same way, whether CONFIG_RELOCATABLE is enabled or not.
>>>>> CONFIG_MODULE_REL_CRCS is no longer needed.
>>>>>
>>>>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
>>>>> objects, but this step is unneeded too.
>>>>>
>>>>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>>>>> Tested-by: Nathan Chancellor <nathan@kernel.org>
>>>>> Tested-by: Nicolas Schier <nicolas@fjasle.eu>
>>>>> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
>>>>
>>>> Problem with v6.0-rc1
>>>> Problem with v5.19
>>>> No problem with v5.18
>>>>
>>>> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
>>>> removing CONFIG_MODULE_REL_CRCS")
>>>>
>>>> The above patch leads to the following problem building
>>>> mpc85xx_defconfig + CONFIG_RELOCATABLE
>>>
>>>
>>>
>>> Is this because the relocation implementation on ppc is incomplete?
>>> (and is it the reason why relock_check.sh exists?)
>>>
>>> arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
>>>
>>>
>>
>> Might be the reason.
>>
>> Is it expected that your patch adds an unsupported relocation ?
>>
>> Why was that relocation type unneeded before ?
>>
>> Thanks
>> Christophe
>
>
> I posted a patch (although I believe my commit is innocent).
>
> https://lore.kernel.org/lkml/20220820165129.1147589-1-masahiroy@kernel.org/T/#u
>
> The relocs_check.sh warnings are gone.
> Please do a boot test.
> Thanks.
>
Yes it works, many Thanks.
The fixes tag should probably be c857c43b34ec ("powerpc: Don't use a
function descriptor for system call table")
Christophe
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-08-20 17:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20220513113930.10488-1-masahiroy@kernel.org>
[not found] ` <20220513113930.10488-3-masahiroy@kernel.org>
2022-08-20 10:02 ` Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS) Christophe Leroy
2022-08-20 12:05 ` Sedat Dilek
2022-08-20 14:10 ` Christophe Leroy
2022-08-20 12:51 ` Masahiro Yamada
2022-08-20 14:15 ` Christophe Leroy
2022-08-20 17:01 ` Masahiro Yamada
2022-08-20 17:51 ` Christophe Leroy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox