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] [day] [month] [year] [list]
Date:   Sun, 1 May 2022 23:28:23 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Mauro Rossi <issor.oruam@...il.com>
Cc:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        masahiroy@...nel.org, michal.lkml@...kovi.net,
        netdev@...r.kernel.org, kabel@...nel.org,
        Chih-Wei Huang <cwhuang@...roid-x86.org>
Subject: Re: FYI: net/phy/marvell10g: android kernel builing error due to
 modpost error

On Sun, May 01, 2022 at 08:51:17PM +0200, Mauro Rossi wrote:
> On Tue, Apr 19, 2022 at 6:39 PM Mauro Rossi <issor.oruam@...il.com> wrote:
> >
> > Hi Russell,
> >
> > On Mon, Apr 18, 2022 at 12:08 PM Russell King (Oracle)
> > <linux@...linux.org.uk> wrote:
> > >
> > > On Mon, Apr 18, 2022 at 11:22:12AM +0200, Mauro Rossi wrote:
> > > > At the final stage of building  Linux 5.18-rc3 with the necessary AOSP
> > > > changes, I am getting the following building error:
> > > >
> > > >   MODPOST modules-only.symvers
> > > > ERROR: modpost: "__compiletime_assert_344"
> > > > [drivers/net/phy/marvell10g.ko] undefined!
> > > > make[2]: *** [/home/utente/r-x86_kernel/kernel/scripts/Makefile.modpost:134:
> > > > modules-only.symvers] Error 1
> > > > make[2]: *** Deleting file 'modules-only.symvers'
> > > > make[1]: *** [/home/utente/r-x86_kernel/kernel/Makefile:1749: modules] Error 2
> > > > make[1]: *** Waiting for unfinished jobs....
> > > >
> > > > It never happened before throughout all my previous android-x86 kernel
> > > > rc cycle build tests, which spanned from linux version 5.10 to linux
> > > > version 5.18rc
> > >
> > > As far as I'm aware, with mainline kernels, marvell10g builds fine.
> >
> > Thanks for response, I will also check that when
> > https://android.googlesource.com/kernel/common-patches/ becomes
> > available for kernel-5.18rc(s)
> >
> > > I'm not sure how to work back from "__compiletime_assert_344" to
> > > where the problem could be. The "344" appears to be generated by
> > > the __COUNTER__ macro - and I don't know how that macro works (debian
> > > annoyingly don't package the GCC info docs, and the info files I have
> > > are out of date.)
> >
> > Looking at the error printout, it seams indeed that modpost parsed
> > modules-only.symvers file line-by-line
> > and (my assumption, correct me if I may be wrong) encountered some
> > 'undefined!' symbol at line 344 of  modules-only.symvers and pointed
> > out that marvell10g.ko module is the one associated with the missing
> > symbol
> >
> > I have tried to copy
> > $OUT/target/product/x86_64/obj/kernel/modules-only.symvers to be able
> > to inspect which symbol is listed at line 344,
> > but even with "watch -n 0.1 cp ..." command I am not able to save the
> > generated modules-only.symvers before it is deleted, therefore I am
> > not able to inspect line 344
> >
> > Is there a way to have modpost modified for printing the symbol
> > instead of the "indirection" of "__compiletime_assert_344" ?
> >
> > As other info, I had to cross compile using prebuilt clang 11.0.2
> > (kernel version constraint) and set  LLVM_IAS=0 to disable the llvm
> > integrated assembler to be able to build, but I don't think that
> > should cause the missing symbol as I don't see any assembler code is
> > needed to build marvell10g.ko module
> >
> > KR
> > Mauro
> 
> Hello,
> 
> I am adding script/mod/modpost.c mantainers to consult them, as I am
> not much familiar with the meaning of the error
> 
> I am building the kernel with Android Build System as part of our
> iso_img target build, gcc based build has always been successful,
> while llvm based build is not working and generates the following
> error, which we are not able to interpret.
> 
> ERROR: modpost: "__compiletime_assert_344"
> [drivers/net/phy/marvell10g.ko] undefined!
> 
> "__compiletime_assert_344" is obviously not a symbol
> used/needed/exported by marvell10g.ko

My guess would be, this is a BUILD_BUG_ON() which is somehow not
working correctly, but is working sufficiently to stop you using a
broken kernel.

**
 * compiletime_assert - break build and emit msg if condition is false
 * @condition: a compile-time constant condition to check
 * @msg:       a message to emit if condition is false
 *
 * In tradition of POSIX assert, this macro will break the build if the
 * supplied condition is *false*, emitting the supplied error message if the
 * compiler has support to do so.
 */
#define compiletime_assert(condition, msg) \
	_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

https://elixir.bootlin.com/linux/v5.18-rc4/source/include/linux/compiler_types.h#L332

# define __compiletime_assert(condition, msg, prefix, suffix)		\
	do {								\
		/*							\
		 * __noreturn is needed to give the compiler enough	\
		 * information to avoid certain possibly-uninitialized	\
		 * warnings (regardless of the build failing).		\
		 */							\
		__noreturn extern void prefix ## suffix(void)		\
			__compiletime_error(msg);			\
		if (!(condition))					\
			prefix ## suffix();				\
	} while (0)

It appears the compiler you are using is not able to emit the supplied
error message, but it is inserting a call to a function which does not
exist.

What you probably want to do is create the .lst file for marvell10g.c
and look through the mixed C/Assembly code and find the BUILD_BUG_ON
which is triggering the issue. It is probably somewhere in an include
file, not marvell10g itself.

The other possibility is that condition is too complex for your
compiler, it cannot evaluate it at build time, allowing the optimizer
to remove the code as impossible to reach. So the compiler has
generated code to actually evaluate condition and so has the call to
the function, which is never going to exist.

The same method to debug this applies, generate the .lst file and take
a look at it.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ