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(+)
diff --git a/arch/s390/tools/relocs.c b/arch/s390/tools/relocs.c
index db8bcbf9d8f8..30a732c808f3 100644
--- a/arch/s390/tools/relocs.c
+++ b/arch/s390/tools/relocs.c
@@ -276,6 +276,8 @@ static int do_reloc(struct section *sec, Elf_Rel *rel)
case R_390_PC32DBL:
case R_390_PLT32DBL:
case R_390_GOTENT:
+ case R_390_GOTPCDBL:
+ case R_390_GOTOFF64:
break;
case R_390_64:
add_reloc(&relocs64, offset);
--
2.40.1
