Odd build breakage in 4.9-rc7

From: Jarod Wilson
Date: Wed Nov 30 2016 - 12:24:55 EST


I'm encountering two different build breakages with 4.9-rc7, using an rpm
spec setup I've been using for every rc dating back to at least 3.10.
First up, and actually dating back earlier in the rc cycle, I get:

----8<----
$ make -s ARCH=x86_64 V=1 -j8 bzImage
...
In file included from ./include/linux/linkage.h:6:0,
from ./include/linux/kernel.h:6,
from ./include/asm-generic/bug.h:13,
from ./arch/x86/include/asm/bug.h:35,
from ./include/linux/bug.h:4,
from ./include/linux/jump_label.h:170,
from ./arch/x86/include/asm/string_64.h:5,
from ./arch/x86/include/asm/string.h:4,
from ./include/linux/string.h:18,
from ./include/uapi/linux/uuid.h:21,
from ./include/linux/uuid.h:19,
from ./include/linux/mod_devicetable.h:12,
from scripts/mod/devicetable-offsets.c:2:
./include/linux/export.h:81:33: fatal error: generated/autoksyms.h: No
such file or directory
#include <generated/autoksyms.h>
^
compilation terminated.
...
make[2]: *** [scripts/mod/devicetable-offsets.s] Error 1
make[1]: *** [scripts/mod] Error 2
make[1]: *** Waiting for unfinished jobs....
----8<----

Now, if I omit the -j8 and do a single-threaded build, then things work
fine. Prarit bisected this failure to commit
9a6fb28a355d2609ace4dab4e6425442c647894d, and indeed, when reverting that
patch and the two that follow it from rc7, parallel make works again.

Up second, once we're past the above, building modules goes splat:

----8<----
$ 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!
...
----8<----

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.
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
here.

To the comment in cd3caefb's changelog: I noticed! ;)

--
Jarod Wilson
jarod@xxxxxxxxxx