On Thu, Mar 07, 2024 at 04:38:20PM +0100, Sumanth Korikkar wrote:
> On Mon, Feb 26, 2024 at 01:55:02PM +0100, Sumanth Korikkar wrote:
> > On Mon, Feb 26, 2024 at 11:54:50AM +0100, Sumanth Korikkar wrote:
> > > Hi Josh,
> > >
> > > On Fri, Feb 23, 2024 at 03:59:39PM -0800, Josh Poimboeuf wrote:
> > > > On Fri, Feb 23, 2024 at 11:03:13AM +0100, Sumanth Korikkar wrote:
> > > > > In the random config generated by lkp test robot
> > > > >
> > > > > CONFIG_TI_CPSW=m
> > > > > CONFIG_TI_DAVINCI_EMAC=y
> > > > >
> > > > > In drivers/net/ethernet/ti/Makefile:
> > > > > 11 obj-$(CONFIG_TI_DAVINCI_EMAC) += ti_davinci_emac.o
> > > > > 12 ti_davinci_emac-y := davinci_emac.o davinci_cpdma.o
> > > > > ...
> > > > > 16 obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
> > > > > 17 ti_cpsw-y := cpsw.o davinci_cpdma.o cpsw_ale.o cpsw_priv.o cpsw_sl.o cpsw_ethtool.o
> > > > >
> > > > > Here davinci_cpdma.o is used in both obj-$(CONFIG_TI_DAVINCI_EMAC) and
> > > > > obj-$(CONFIG_TI_CPSW), one built as inbuilt and one built as module
> > > > > correspondingly (randconfig)
> > > > >
> > > > > This leads to conflict in Kbuild and results in linking davinci_cpdma.o
> > > > > in vmlinux.
> > > > > * However, davinci_cpdma.o is built with -DMODULE -fPIC.
> > > > > * vmlinux is built with -fno-PIE.
> > > > >
> > > > > This leads to R_390_GOTENT and R_390_GOTDBL entries in vmlinux, which is
> > > > > not expected when building kernel with -fno-PIE.
> > > >
> > > > Nice.
> > > >
> > > > I suppose the current s390 memory model wouldn't support removing
> > > > -fPIC for modules?
> > >
> > > Answer from our toolchain team - Andreas Krebbel: It should be ideally
> > > feasible to build modules without -fPIC on s390.
> >
> > FWIW, I'm looking into this right now. Let's see how things go.
>
> From d6641b8492ade37709a7099cea0ef71f29d062d0 Mon Sep 17 00:00:00 2001
> From: Sumanth Korikkar <sumanthk@xxxxxxxxxxxxx>
> Date: Thu, 7 Mar 2024 09:46:11 +0100
> Subject: [PATCH] s390/tools: handle rela R_390_GOTPCDBL/R_390_GOTOFF64
>
> lkp test robot reported unhandled relocation type: R_390_GOTPCDBL, when
> kernel is built with -fno-PIE. relocs tool reads vmlinux and handles
> absolute relocations. PC relative relocs doesn't need adjustment.
>
> Also, the R_390_GOTPCDBL/R_390_GOTOFF64 relocations are present
> currently only when KASAN is enabled.
>
> The following program can create a R_390_GOTPCDBL/R_390_GOTOFF64 reloc
> (with fPIE/fPIC).
>
> void funcb(int *b) {
> *b = *b + 100;
> }
>
> void gen_gotoff(void)
> {
> int b = 10;
> funcb (&b);
> }
>
> gcc -c sample.c -fPIC -fsanitize=kernel-address --param asan-stack=1
>
> The above example (built with -fPIC) was linked to one of the
> built-in.a (built with -fno-PIE) and checked for correctness with kaslr
> enabled. Both the relocs turns out relative and can be skipped.
>
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@xxxxxxxxx/
> Fixes: 55dc65b46023 ("s390: add relocs tool")
> Signed-off-by: Sumanth Korikkar <sumanthk@xxxxxxxxxxxxx>
> ---
> arch/s390/tools/relocs.c | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Vasily Gorbik <gor@xxxxxxxxxxxxx>
