[s390:features 97/98] Unsupported relocation type: 21

[s390:features 97/98] Unsupported relocation type: 21

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
head:   4a5993287467d2d0401503256dc9d2690c7f2020
commit: 778666df60f0d96f215e33e27448de47a2207fb3 [97/98] s390: compile relocatable kernel without -fPIE
config: s390-randconfig-002-20231016 (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/

All errors (new ones prefixed by >>):

>> Unsupported relocation type: 21

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [s390:features 97/98] Unsupported relocation type: 21

[Josh Poimboeuf]

On Thu, Feb 22, 2024 at 02:42:01PM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
> head:   4a5993287467d2d0401503256dc9d2690c7f2020
> commit: 778666df60f0d96f215e33e27448de47a2207fb3 [97/98] s390: compile relocatable kernel without -fPIE
> config: s390-randconfig-002-20231016 (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/config)
> compiler: s390-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
> >> Unsupported relocation type: 21

This is R_390_GOTPCDBL, which I believe can be ignored by the relocs
tool since it's related to the GOT.

I'm not able to recreate with my s390 toolchain (12.2.0), but I suspect
the following fixes it:

diff --git a/arch/s390/tools/relocs.c b/arch/s390/tools/relocs.c
index db8bcbf9d8f8..ad3773dc1f95 100644
--- a/arch/s390/tools/relocs.c
+++ b/arch/s390/tools/relocs.c
@@ -276,6 +276,7 @@ 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:
 		break;
 	case R_390_64:
 		add_reloc(&relocs64, offset);

Re: [s390:features 97/98] Unsupported relocation type: 21

[Yujie Liu]

Hi Josh,

On Thu, Feb 22, 2024 at 09:37:27AM -0800, Josh Poimboeuf wrote:
> On Thu, Feb 22, 2024 at 02:42:01PM +0800, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
> > head:   4a5993287467d2d0401503256dc9d2690c7f2020
> > commit: 778666df60f0d96f215e33e27448de47a2207fb3 [97/98] s390: compile relocatable kernel without -fPIE
> > config: s390-randconfig-002-20231016 (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/config)
> > compiler: s390-linux-gcc (GCC) 13.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> Unsupported relocation type: 21
> 
> This is R_390_GOTPCDBL, which I believe can be ignored by the relocs
> tool since it's related to the GOT.
> 
> I'm not able to recreate with my s390 toolchain (12.2.0), but I suspect
> the following fixes it:
> 
> diff --git a/arch/s390/tools/relocs.c b/arch/s390/tools/relocs.c
> index db8bcbf9d8f8..ad3773dc1f95 100644
> --- a/arch/s390/tools/relocs.c
> +++ b/arch/s390/tools/relocs.c
> @@ -276,6 +276,7 @@ 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:
>  		break;
>  	case R_390_64:
>  		add_reloc(&relocs64, offset);
> 

We tested the diff above. The "Unsupported relocation type: 21" error
goes away but another "Unsupported relocation type: 28" error appears.
Refer to arch/s390/include/asm/elf.h, seems R_390_GOTOFF64 also needs to
be taken care of.

The original error is as below, which can be reproduced by both gcc-12
and gcc-13 in our tests:

$ wget https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/config -O .config

$ s390-linux-gcc --version
s390-linux-gcc (GCC) 13.2.0
$ make ARCH=s390 CROSS_COMPILE=s390-linux- olddefconfig
$ make -j72 ARCH=s390 CROSS_COMPILE=s390-linux-
...
  RELOCS arch/s390/boot/relocs.S
Unsupported relocation type: 21
make[2]: *** [arch/s390/boot/Makefile:118: arch/s390/boot/relocs.S] Error 1
make[2]: *** Deleting file 'arch/s390/boot/relocs.S'
make[1]: *** [arch/s390/Makefile:142: bzImage] Error 2

After adding "case R_390_GOTPCDBL:":

$ make -j72 ARCH=s390 CROSS_COMPILE=s390-linux-
...
  RELOCS arch/s390/boot/relocs.S
Unsupported relocation type: 28
make[2]: *** [arch/s390/boot/Makefile:118: arch/s390/boot/relocs.S] Error 1
make[2]: *** Deleting file 'arch/s390/boot/relocs.S'

Not sure if R_390_GOTOFF64 can also be ignored as R_390_GOTPCDBL. We
tried this and the bzImage is successfully built:

$ make -j72 ARCH=s390 CROSS_COMPILE=s390-linux-
  HOSTCC  arch/s390/tools/relocs
  CALL    scripts/checksyscalls.sh
  RELOCS arch/s390/boot/relocs.S
  AS      arch/s390/boot/relocs.o
  LD      arch/s390/boot/vmlinux.syms
  DUMPSYMS arch/s390/boot/vmlinux.syms
  OBJCOPY arch/s390/boot/syms.o
  LD      arch/s390/boot/vmlinux
  SECTCMP .boot.data
  SECTCMP .boot.preserved.data
  OBJCOPY arch/s390/boot/bzImage

This is a randconfig build test, and issue can be fixed by ignoring both
R_390_GOTPCDBL and R_390_GOTOFF64, but not sure if this is a complete
fix for build tests on all kinds of configs.

Seems there are several other GOT related constants defined in
arch/s390/include/asm/elf.h. Could you help check if there may be
other ones to be handled together?

Thanks,
Yujie

Re: [s390:features 97/98] Unsupported relocation type: 21

[Sumanth Korikkar]

On Thu, Feb 22, 2024 at 02:42:01PM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
> head:   4a5993287467d2d0401503256dc9d2690c7f2020
> commit: 778666df60f0d96f215e33e27448de47a2207fb3 [97/98] s390: compile relocatable kernel without -fPIE
> config: s390-randconfig-002-20231016 (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/config)
> compiler: s390-linux-gcc (GCC) 13.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
> >> Unsupported relocation type: 21
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>

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.

Debug data:
==========
1.
  CALL    ../scripts/checksyscalls.sh
  AR      drivers/phy/ti/built-in.a
  CC [M]  drivers/phy/ti/phy-gmii-sel.o
../scripts/Makefile.build:243: ../drivers/net/ethernet/ti/Makefile:
davinci_cpdma.o is added to multiple modules: ti_cpsw ti_davinci_emac <<<<<<<<
  CC [M]  drivers/net/ethernet/ti/davinci_cpdma.o
...
  CC [M]  drivers/net/ethernet/ti/cpsw.o
  CC [M]  drivers/net/ethernet/ti/cpsw_ale.o
  CC [M]  drivers/net/ethernet/ti/cpsw_priv.o
  CC [M]  drivers/net/ethernet/ti/cpsw_sl.o
  CC [M]  drivers/net/ethernet/ti/cpsw_ethtool.o
  AR      drivers/phy/built-in.a
  AR      drivers/net/ethernet/ti/built-in.a
  LD [M]  drivers/net/ethernet/ti/ti_cpsw.o
  AR      drivers/net/ethernet/built-in.a
  AR      drivers/net/built-in.a
  AR      drivers/built-in.a
  AR      built-in.a


2.
ti/.davinci_cpdma.o.cmd:savedcmd_drivers/net/ethernet/ti/davinci_cpdma.o
:= This uses -DMODULE -fPIC  <<<<<<

built-in.a:ti/davinci_cpdma.o/ <<<<<


Hence, the error by lkp robot. No fix should be necessary in
s390/tools/relocs.c

I think it should be either fixed in ti driver or in the kbuild.

Thank you,
Sumanth

Re: [s390:features 97/98] Unsupported relocation type: 21

[Sumanth Korikkar]

On Fri, Feb 23, 2024 at 11:03:13AM +0100, Sumanth Korikkar wrote:
> On Thu, Feb 22, 2024 at 02:42:01PM +0800, kernel test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
> > head:   4a5993287467d2d0401503256dc9d2690c7f2020
> > commit: 778666df60f0d96f215e33e27448de47a2207fb3 [97/98] s390: compile relocatable kernel without -fPIE
> > config: s390-randconfig-002-20231016 (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/config)
> > compiler: s390-linux-gcc (GCC) 13.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240222/202402221404.T2TGs8El-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> Unsupported relocation type: 21
> > 
> > -- 
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
> >
> 
> 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.

typo: R_390_GOTPCDBL

Thank you,
Sumanth

Re: [s390:features 97/98] Unsupported relocation type: 21

[Josh Poimboeuf]

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?

Otherwise each driver could get its own copy of the object file:

diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index d8590304f3df..ef6591b6a4c9 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -9,14 +9,14 @@ obj-$(CONFIG_TI_CPSW_SWITCHDEV) += cpsw-common.o
 
 obj-$(CONFIG_TLAN) += tlan.o
 obj-$(CONFIG_TI_DAVINCI_EMAC) += ti_davinci_emac.o
-ti_davinci_emac-y := davinci_emac.o davinci_cpdma.o
+ti_davinci_emac-y := davinci_emac.o emac_cpdma.o
 obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
 obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
 obj-$(CONFIG_TI_CPTS) += cpts.o
 obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
-ti_cpsw-y := cpsw.o davinci_cpdma.o cpsw_ale.o cpsw_priv.o cpsw_sl.o cpsw_ethtool.o
+ti_cpsw-y := cpsw.o cpsw_cpdma.o cpsw_ale.o cpsw_priv.o cpsw_sl.o cpsw_ethtool.o
 obj-$(CONFIG_TI_CPSW_SWITCHDEV) += ti_cpsw_new.o
-ti_cpsw_new-y := cpsw_switchdev.o cpsw_new.o davinci_cpdma.o cpsw_ale.o cpsw_sl.o cpsw_priv.o cpsw_ethtool.o
+ti_cpsw_new-y := cpsw_switchdev.o cpsw_new.o cpsw_new_cpdma.o cpsw_ale.o cpsw_sl.o cpsw_priv.o cpsw_ethtool.o
 
 obj-$(CONFIG_TI_KEYSTONE_NETCP) += keystone_netcp.o
 keystone_netcp-y := netcp_core.o cpsw_ale.o
diff --git a/drivers/net/ethernet/ti/cpsw_cpdma.c b/drivers/net/ethernet/ti/cpsw_cpdma.c
new file mode 100644
index 000000000000..017156225e7f
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw_cpdma.c
@@ -0,0 +1 @@
+#include "davinci_cpdma.c"
diff --git a/drivers/net/ethernet/ti/cpsw_new_cpdma.c b/drivers/net/ethernet/ti/cpsw_new_cpdma.c
new file mode 100644
index 000000000000..017156225e7f
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw_new_cpdma.c
@@ -0,0 +1 @@
+#include "davinci_cpdma.c"
diff --git a/drivers/net/ethernet/ti/emac_cpdma.c b/drivers/net/ethernet/ti/emac_cpdma.c
new file mode 100644
index 000000000000..017156225e7f
--- /dev/null
+++ b/drivers/net/ethernet/ti/emac_cpdma.c
@@ -0,0 +1 @@
+#include "davinci_cpdma.c"

Re: [s390:features 97/98] Unsupported relocation type: 21

[Sumanth Korikkar]

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.

> 
> Otherwise each driver could get its own copy of the object file:
> 
> diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
> index d8590304f3df..ef6591b6a4c9 100644
> --- a/drivers/net/ethernet/ti/Makefile
> +++ b/drivers/net/ethernet/ti/Makefile
> @@ -9,14 +9,14 @@ obj-$(CONFIG_TI_CPSW_SWITCHDEV) += cpsw-common.o
>  
>  obj-$(CONFIG_TLAN) += tlan.o
>  obj-$(CONFIG_TI_DAVINCI_EMAC) += ti_davinci_emac.o
> -ti_davinci_emac-y := davinci_emac.o davinci_cpdma.o
> +ti_davinci_emac-y := davinci_emac.o emac_cpdma.o
>  obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
>  obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
>  obj-$(CONFIG_TI_CPTS) += cpts.o
>  obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
> -ti_cpsw-y := cpsw.o davinci_cpdma.o cpsw_ale.o cpsw_priv.o cpsw_sl.o cpsw_ethtool.o
> +ti_cpsw-y := cpsw.o cpsw_cpdma.o cpsw_ale.o cpsw_priv.o cpsw_sl.o cpsw_ethtool.o
>  obj-$(CONFIG_TI_CPSW_SWITCHDEV) += ti_cpsw_new.o
> -ti_cpsw_new-y := cpsw_switchdev.o cpsw_new.o davinci_cpdma.o cpsw_ale.o cpsw_sl.o cpsw_priv.o cpsw_ethtool.o
> +ti_cpsw_new-y := cpsw_switchdev.o cpsw_new.o cpsw_new_cpdma.o cpsw_ale.o cpsw_sl.o cpsw_priv.o cpsw_ethtool.o
>  
>  obj-$(CONFIG_TI_KEYSTONE_NETCP) += keystone_netcp.o
>  keystone_netcp-y := netcp_core.o cpsw_ale.o
> diff --git a/drivers/net/ethernet/ti/cpsw_cpdma.c b/drivers/net/ethernet/ti/cpsw_cpdma.c
> new file mode 100644
> index 000000000000..017156225e7f
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/cpsw_cpdma.c
> @@ -0,0 +1 @@
> +#include "davinci_cpdma.c"
> diff --git a/drivers/net/ethernet/ti/cpsw_new_cpdma.c b/drivers/net/ethernet/ti/cpsw_new_cpdma.c
> new file mode 100644
> index 000000000000..017156225e7f
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/cpsw_new_cpdma.c
> @@ -0,0 +1 @@
> +#include "davinci_cpdma.c"
> diff --git a/drivers/net/ethernet/ti/emac_cpdma.c b/drivers/net/ethernet/ti/emac_cpdma.c
> new file mode 100644
> index 000000000000..017156225e7f
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/emac_cpdma.c
> @@ -0,0 +1 @@
> +#include "davinci_cpdma.c"
> 

Tried compiling it,

When I enabled both CONFIG_TI_CPSW_SWITCHDEV and CONFIG_TI_DAVINCI_EMAC
to y, it could lead to the following:

  LD      vmlinux.o
ld: drivers/net/ethernet/ti/cpsw_new_cpdma.o: in function `cpdma_ctlr_create':
linux/drivers/net/ethernet/ti/davinci_cpdma.c:511:
multiple definition of `cpdma_ctlr_create';
drivers/net/ethernet/ti/emac_cpdma.o:linux/drivers/net/ethernet/ti/davinci_cpdma.c:511:
first defined here

Thanks,
Sumanth

Re: [s390:features 97/98] Unsupported relocation type: 21

[Sumanth Korikkar]

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.

Re: [s390:features 97/98] Unsupported relocation type: 21

[Sumanth Korikkar]

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@linux.ibm.com>
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@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
Fixes: 55dc65b46023 ("s390: add relocs tool")
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
---
 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

Re: [s390:features 97/98] Unsupported relocation type: 21

[Sumanth Korikkar]

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@linux.ibm.com>
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@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
Fixes: 55dc65b46023 ("s390: add relocs tool")
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
---
 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

Re: [s390:features 97/98] Unsupported relocation type: 21

[Vasily Gorbik]

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@linux.ibm.com>
> 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@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
> Fixes: 55dc65b46023 ("s390: add relocs tool")
> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
> ---
>  arch/s390/tools/relocs.c | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Vasily Gorbik <gor@linux.ibm.com>

Re: [s390:features 97/98] Unsupported relocation type: 21

[Heiko Carstens]

On Thu, Mar 07, 2024 at 04:38:20PM +0100, Sumanth Korikkar wrote:
> From d6641b8492ade37709a7099cea0ef71f29d062d0 Mon Sep 17 00:00:00 2001
> From: Sumanth Korikkar <sumanthk@linux.ibm.com>
> 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@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202402221404.T2TGs8El-lkp@intel.com/
> Fixes: 55dc65b46023 ("s390: add relocs tool")
> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
> ---
>  arch/s390/tools/relocs.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks!