Re: Odd build breakage in 4.9-rc7

From: Jarod Wilson
Date: Wed Nov 30 2016 - 16:08:32 EST

On 2016-11-30 3:52 PM, Paul Bolle wrote:
On Wed, 2016-11-30 at 12:24 -0500, Jarod Wilson wrote:
Up second, once we're past the above, building modules goes splat:

$ make -s ARCH=x86_64 V=1 -j8 modules
ERROR: "module_put" [virt/lib/irqbypass.ko] undefined!
ERROR: "mutex_unlock" [virt/lib/irqbypass.ko] undefined!
ERROR: "mutex_lock" [virt/lib/irqbypass.ko] undefined!

There are similar ERROR lines to the tune of 145k lines of output,
basically for every single module and symbol in the build. This breakage
was bisected to commit cd3caefb4663e3811d37cc2afad3cce642d60061, which
looks fairly innocuous, but when reverted, builds work fine again.

I ran into a modules build printing over 100K ERROR lines a month ago:<1478165881-9263-1-git-send-email-pebolle@xxxxxxxxxx>

That had to do with setting TRIM_UNUSED_KSYMS and so unsetting UNUSED_SYMBOLS,
as far as I could tell. Did you perhaps also have UNUSED_SYMBOLS unset when
your modules build when splat?


And did your bzImage build by any chance print this (to stderr):
sed: can't read .tmp_versions/*.mod: No such file or directory

Yep, I do see this now that I look back at the output from the bzImage stage.

If so I might have run into your second issue a month ago already, which makes
your bisect to commit cd3caefb4663 ("Fix subtle CONFIG_MODVERSIONS problems")
suspect. Or did that bisect not cover the second issue?

Hm. No, that bisect was indeed for this issue. Clean build each time, freshly unpacked 4.8 + rc6 patch applied + rc6-to-7 bisect patch.

Multi-threaded make vs. single-threaded doesn't matter, setting
CONFIG_BROKEN=y or '# CONFIG_MODVERSIONS is not set' don't make a
difference, and interestingly, if instead of split 'make bzImage' and
'make modules', I just do a single 'make', then things DO build
successfully, so I'm a wee bit baffled as to what's actually going on

Likewise (ie, both the modules splat going away if doing a single make and
being baffled, but more that a wee bit).

Seems like it could be a case of "this patch just happens to tickle the issue in just the right way so as to trigger" if you saw this already a month prior. Linus' commit message there says things were already broken when that went in, I don't know the details of how and haven't yet tried to uncover them.

Jarod Wilson