linux-kernel - Re: next-20251002: S390: gcc-8-defconfig: symbol `.modinfo' required but not present

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251006234114.GA659425@ax162>
Date: Mon, 6 Oct 2025 16:41:14 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Heiko Carstens <hca@...ux.ibm.com>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>,
	Alexey Gladkov <legion@...nel.org>, linux-s390@...r.kernel.org,
	open list <linux-kernel@...r.kernel.org>,
	lkft-triage@...ts.linaro.org,
	Linux Regressions <regressions@...ts.linux.dev>,
	Arnd Bergmann <arnd@...db.de>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	Anders Roxell <anders.roxell@...aro.org>,
	Ben Copeland <benjamin.copeland@...aro.org>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Alexander Gordeev <agordeev@...ux.ibm.com>
Subject: Re: next-20251002: S390: gcc-8-defconfig: symbol `.modinfo' required
 but not present - no symbols

Hi Heiko,

On Mon, Oct 06, 2025 at 07:47:40PM +0200, Heiko Carstens wrote:
> [full quote below, adding Alexey and Nathan]
> 
> On Mon, Oct 06, 2025 at 04:55:56PM +0530, Naresh Kamboju wrote:
> > The S390 defconfig builds failed on the Linux next-20251002 tag build due
> > to following build warnings / errors with gcc-8 toolchain.
> > 
> > * S390, build
> >   - gcc-8-defconfig
> > 
> > First seen on next-20251002
> > Good: next-20250929
> > Bad: next-20251002..next-20251003
> > 
> > Regression Analysis:
> > - New regression? yes
> > - Reproducibility? yes
> > 
> > Test regression: next-20251002: S390: gcc-8-defconfig: symbol
> > `.modinfo' required but not present - no symbols
> > 
> > Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> > 
> > ### Build error log
> > s390x-linux-gnu-ld: .tmp_vmlinux1: warning: allocated section
> > `.got.plt' not in segment
> > s390x-linux-gnu-ld: .tmp_vmlinux2: warning: allocated section
> > `.got.plt' not in segment
> > s390x-linux-gnu-ld: vmlinux.unstripped: warning: allocated section
> > `.got.plt' not in segment
> > s390x-linux-gnu-objcopy: vmlinux: warning: allocated section
> > `.got.plt' not in segment
> > s390x-linux-gnu-objcopy: stM7JmYX: warning: allocated section
> > `.got.plt' not in segment
> > s390x-linux-gnu-objcopy: stM7JmYX: symbol `.modinfo' required but not present
> > s390x-linux-gnu-objcopy:stM7JmYX: no symbols
> > make[3]: *** [scripts/Makefile.vmlinux:97: vmlinux] Error 1
> > 
> > 
> > ## Source
> > * Kernel version: 6.17.0
> > * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
> > * Git commit: 47a8d4b89844f5974f634b4189a39d5ccbacd81c
> > * Architectures: S390
> > * Toolchains: gcc-8
> > * Kconfigs: defconfig
> > 
> > ## Build
> > * Build log: https://storage.tuxsuite.com/public/linaro/lkft/builds/33YUHdDpSLSMJfU4MFvRyEUQuDn/build.log
> > * Build details:
> > https://regressions.linaro.org/lkft/linux-next-master/next-20251003/build/gcc-8-defconfig/
> > * Build plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/builds/33YUHdDpSLSMJfU4MFvRyEUQuDn
> > * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/33YUHdDpSLSMJfU4MFvRyEUQuDn/
> > * Kernel config:
> > https://storage.tuxsuite.com/public/linaro/lkft/builds/33YUHdDpSLSMJfU4MFvRyEUQuDn/config
> > 
> > 
> > ## Steps to reproduce
> >   tuxmake --runtime podman --target-arch s390 --toolchain gcc-8
> > --kconfig defconfig --kconfig-add CONFIG_DEBUG_INFO_BTF=n
> 
> Isn't the above exactly what is supposed to be addressed with commit
> 8d18ef04f940 ("s390: vmlinux.lds.S: Reorder sections")? Or did something
> change with the commit? Didn't check, and might look into this tomorrow,
> but adding Alexey and Nathan already now :)

I did not change anything with that change before applying it so I would
have expected this issue to be avoided...

I can reproduce this issue with the tuxmake command above on
next-20251006 but I am not able to reproduce it with korg-gcc-8, so I
wonder if this is something toolchain specific? I will have a further
look tomorrow but if you or Alexey beat me to it, feel free to share
follow up findings.

Cheers,
Nathan