Odd build breakage in 4.9-rc7
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! ;)
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 5 lines · Jarod Wilson
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.
I seriously doubt that commit really makes a difference, and I think it was just random luck.
Do you perhaps have ccache installed?
Because ccache at some point broke dependency generation of "gcc -MM" that the kernel build system uses, giving those random "No such file" build errors.
Try uninstalling ccache and see if that helps.
Linus
Quoted 10 lines · Linus Torvalds
Quoted 5 lines · Jarod Wilson
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.I seriously doubt that commit really makes a difference, and I think it was just random luck.
Quoted 8 lines
Do you perhaps have ccache installed?
Because ccache at some point broke dependency generation of "gcc -MM" that the kernel build system uses, giving those random "No such file" build errors.
Try uninstalling ccache and see if that helps.
I reported this last week on LKML and I'm building on a freshly installed systems that do not have ccache installed.
For example,
[root@intel-brickland-04 linux]# rpm -q ccache
package ccache is not installed
[root@intel-brickland-04 linux]# which ccache/usr/bin/which: no ccache in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/libexec/git-core:/root/bin)
In my case I tracked this to commit 3637efb00864 ("x86/mce: Add PCI quirks to identify Xeons with machine check recovery") which adds the include for generated/autoksyms.h.
Searching LKML and I came across a report from Ken Moffat from a month ago:
http://marc.info/?l=linux-kernel&m=147794681124332&w=2
Also cc'ing linux-kbuild.
P.
Quoted 2 lines
Linus
On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <[email protected]> wrote:
]>
Quoted 3 lines
In my case I tracked this to commit
3637efb00864("x86/mce: Add PCI quirks to identify Xeons with machine check recovery") which adds the include forgenerated/autoksyms.h.
Ok, that at least makes some sense. The other blamed commit did not seem to possibly make a difference.
Quoted 3 lines
Searching LKML and I came across a report from Ken Moffat from a month ago:
Does a "make clean" get rid of it forever? Or does it come back?
If it's a one-time dependency issue that is because some header dependency addition that the automatic dependency generator hadn't caught, that might explain a bisection failure too: once the file happens to get rebuilt (and the dependencies re-done), it starts working even though the "happens to be rebuilt" had nothing to do with the original bug.
Linus
Quoted 6 lines · Linus Torvalds
On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <[email protected]> wrote:
]>Quoted 3 lines
In my case I tracked this to commit
3637efb00864("x86/mce: Add PCI quirks to identify Xeons with machine check recovery") which adds the include forgenerated/autoksyms.h.
Quoted 8 lines
Ok, that at least makes some sense. The other blamed commit did not seem to possibly make a difference.
Quoted 3 lines
Searching LKML and I came across a report from Ken Moffat from a month ago:
Does a "make clean" get rid of it forever? Or does it come back?
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112
(IOW, it occurs 100% of the time for me on a clean tree.)
To work around the bug I have to do
1. checkout latest linux.git 2. comment out the include for generated/autoksyms.h at include/linux/export.h:81 3. compile with -j112
This fails loudly, but then I do
4. uncomment the include for generated/autoksyms.h at include/linux/export.h:81
5. make -j112
and this completes with a bootable kernel AFAICT.
Quoted 7 lines
If it's a one-time dependency issue that is because some header dependency addition that the automatic dependency generator hadn't caught, that might explain a bisection failure too: once the file happens to get rebuilt (and the dependencies re-done), it starts working even though the "happens to be rebuilt" had nothing to do with the original bug.
Hopefully the linux-kbuild folks might be able to point us in the right direction for a fix.
P.
Quoted 30 lines · Prarit Bhargava
Quoted 6 lines · Linus Torvalds
On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <[email protected]> wrote:
]>Quoted 3 lines
In my case I tracked this to commit
3637efb00864("x86/mce: Add PCI quirks to identify Xeons with machine check recovery") which adds the include forgenerated/autoksyms.h.Quoted 8 lines
Ok, that at least makes some sense. The other blamed commit did not seem to possibly make a difference.
Quoted 3 lines
Searching LKML and I came across a report from Ken Moffat from a month ago:
Does a "make clean" get rid of it forever? Or does it come back?
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
To work around the bug I have to do
1. checkout latest linux.git 2. comment out the include for generated/autoksyms.h at include/linux/export.h:81 3. compile with -j112
Quoted 6 lines
This fails loudly, but then I do
4. uncomment the include for
generated/autoksyms.hatinclude/linux/export.h:81
5. make -j112and this completes with a bootable kernel AFAICT.
In my case, I first noticed this with rpm builds, which are unpacking a tarball every time. I did have ccache installed, but have removed it, to no avail. I still get this failure. Reverting these three patches...
9a6fb28a355d2609ace4dab4e6425442c647894d3637efb00864f465baebd49464e58319fd295b65ffb173e657fa8123bffa2a169e124b4bca0b5bc4
...gets me a working build every time. So I'm not so sure these patches are completely innocent. They may not be directly at fault, but certainly seem to be involved in causing things to get tripped up.
Quoted 9 lines
Quoted 6 lines
If it's a one-time dependency issue that is because some header dependency addition that the automatic dependency generator hadn't caught, that might explain a bisection failure too: once the file happens to get rebuilt (and the dependencies re-done), it starts working even though the "happens to be rebuilt" had nothing to do with the original bug.
Hopefully the linux-kbuild folks might be able to point us in the right direction for a fix.
Indeed. I'm mostly clueless here. Well, mostly clueless, period, but even more so here. And with the CONFIG_MODVERSIONS part of my original mail, which I guess I should also re-test with ccache uninstalled...
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 7 lines · Prarit Bhargava
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
I suspect it's not new, it's just that you are able to hit the timing just right (and the new include presumable makes that just be much easier).
The rules for generating include/generated/autoksyms.h aren't new, they go back to at least 4.7.
Adding Nico to the cc, since he's the person to blame for autokeysyms, and might have some idea why the dependency wouldn't be done in time.
Linus
Quoted 8 lines · Linus Torvalds
Quoted 7 lines · Prarit Bhargava
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
I don't have access to such hardware where -j112 could ever make sense. :-) In other words, I can't reproduce regardless of the -j value I try.
Quoted 3 lines
I suspect it's not new, it's just that you are able to hit the timing just right (and the new include presumable makes that just be much easier).
Here's the best fix I can think of. I can't convince myself any other location would be 100% safe. Obviously I can't confirm if this actually fixes anything.
----- >8
Subject: kbuild: make sure autoksyms.h exists early
Some people are able to trigger a race where autoksyms.h is used before its empty version is even created. Let's create it at the same time as the directory holding it is created.
Makefile +0 -2
@@ -1019,8 +1019,6 @@ prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ include/config/auto.conf $(cmd_crmodverdir) - $(Q)test -e include/generated/autoksyms.h || \ - touch include/generated/autoksyms.h archprepare: archheaders archscripts prepare1 scripts_basic
scripts/kconfig/Makefile +2 -0
@@ -35,6 +35,8 @@ nconfig: $(obj)/nconf silentoldconfig: $(obj)/conf $(Q)mkdir -p include/config include/generated + $(Q)test -e include/generated/autoksyms.h || \ + touch include/generated/autoksyms.h $< $(silent) --$@ $(Kconfig) localyesconfig localmodconfig: $(obj)/streamline_config.pl $(obj)/conf
Quoted 4 lines · Nicolas Pitre
Quoted 2 lines · Linus Torvalds
Quoted 1 line · Prarit Bhargava
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
I don't have access to such hardware where -j112 could ever make sense. :-)
:) I could push the builds onto the -j256 but I'm doing other stuff over there. :)
Quoted 6 lines
In other words, I can't reproduce regardless of the -j value I try.
Quoted 3 lines
I suspect it's not new, it's just that you are able to hit the timing just right (and the new include presumable makes that just be much easier).
Quoted 7 lines
Here's the best fix I can think of. I can't convince myself any other location would be 100% safe. Obviously I can't confirm if this actually fixes anything.
----- >8
Subject: kbuild: make sureautoksyms.hexists early
I'm building with this patch on top of latest now. I will put it in a tight loop and clear the drop_caches between builds to see if I can make it fail.
Thanks Nicolas -- your help is very much appreciated.
P.
Prarit Bhargava
Tested-byQuoted 50 lines · Nicolas Pitre
Quoted 8 lines · Linus Torvalds
Quoted 7 lines · Prarit Bhargava
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
I don't have access to such hardware where -j112 could ever make sense. :-) In other words, I can't reproduce regardless of the -j value I try.
Quoted 3 lines
I suspect it's not new, it's just that you are able to hit the timing just right (and the new include presumable makes that just be much easier).
Here's the best fix I can think of. I can't convince myself any other location would be 100% safe. Obviously I can't confirm if this actually fixes anything.
----- >8
Subject: kbuild: make sureautoksyms.hexists earlySome people are able to trigger a race where
autoksyms.his used before its empty version is even created. Let's create it at the same time as the directory holding it is created.Signed-off-by Nicolas Pitre <[email protected]>Makefile +0
-2@@ -1019,8 +1019,6 @@ prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ include/config/auto.conf $(cmd_crmodverdir) - $(Q)test -e include/generated/autoksyms.h || \ - touch include/generated/autoksyms.h archprepare: archheaders archscripts prepare1 scripts_basicscripts/kconfig/Makefile +0
-0
scripts/kconfig/Makefile nconfig: $(obj)/nconf · line 42
Quoted 8 lines
scripts/kconfig/Makefile +2
-0@@ -35,6 +35,8 @@ nconfig: $(obj)/nconf silentoldconfig: $(obj)/conf $(Q)mkdir -p include/config include/generated + $(Q)test -e include/generated/autoksyms.h || \ + touch include/generated/autoksyms.h $< $(silent) --$@ $(Kconfig) localyesconfig localmodconfig: $(obj)/streamline_config.pl $(obj)/conf
The testing was successful.
After testing an hour of builds with different -j values, I'm no longer seeing any compile issues when this patch is applied. When I remove the patch the compile error returns so I'm going to say that this patch fixed it.
Thanks again Nicolas.
P.
Jarod Wilson
Tested-byQuoted 64 lines · Prarit Bhargava
Quoted 50 lines · Nicolas Pitre
Quoted 8 lines · Linus Torvalds
Quoted 7 lines · Prarit Bhargava
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
I don't have access to such hardware where -j112 could ever make sense. :-) In other words, I can't reproduce regardless of the -j value I try.
Quoted 3 lines
I suspect it's not new, it's just that you are able to hit the timing just right (and the new include presumable makes that just be much easier).
Here's the best fix I can think of. I can't convince myself any other location would be 100% safe. Obviously I can't confirm if this actually fixes anything.
----- >8
Subject: kbuild: make sureautoksyms.hexists earlySome people are able to trigger a race where
autoksyms.his used before its empty version is even created. Let's create it at the same time as the directory holding it is created.Signed-off-by Nicolas Pitre <[email protected]>Makefile +0
-2@@ -1019,8 +1019,6 @@ prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ include/config/auto.conf $(cmd_crmodverdir) - $(Q)test -e include/generated/autoksyms.h || \ - touch include/generated/autoksyms.h archprepare: archheaders archscripts prepare1 scripts_basicscripts/kconfig/Makefile +0
-0scripts/kconfig/Makefile nconfig: $(obj)/nconf · line 42
Quoted 8 lines
scripts/kconfig/Makefile +2
-0@@ -35,6 +35,8 @@ nconfig: $(obj)/nconf silentoldconfig: $(obj)/conf $(Q)mkdir -p include/config include/generated + $(Q)test -e include/generated/autoksyms.h || \ + touch include/generated/autoksyms.h $< $(silent) --$@ $(Kconfig) localyesconfig localmodconfig: $(obj)/streamline_config.pl $(obj)/confThe testing was successful.
Quoted 7 lines
After testing an hour of builds with different -j values, I'm no longer seeing any compile issues when this patch is applied. When I remove the patch the compile error returns so I'm going to say that this patch fixed it.
Thanks again Nicolas.
Tested-by Prarit Bhargava <[email protected]>
Looks good here as well, can do parallel make w/o reverting Tony's patches again.
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 27 lines · Prarit Bhargava
Quoted 6 lines · Linus Torvalds
On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <[email protected]> wrote:
]>Quoted 3 lines
In my case I tracked this to commit
3637efb00864("x86/mce: Add PCI quirks to identify Xeons with machine check recovery") which adds the include forgenerated/autoksyms.h.Quoted 8 lines
Ok, that at least makes some sense. The other blamed commit did not seem to possibly make a difference.
Quoted 3 lines
Searching LKML and I came across a report from Ken Moffat from a month ago:
Does a "make clean" get rid of it forever? Or does it come back?
It comes back. The steps to reproduce this are:
1. checkout latest linux.git
2. make -j112(IOW, it occurs 100% of the time for me on a clean tree.)
To work around the bug I have to do
Quoted 7 lines
1. checkout latest linux.git 2. comment out the include for generated/autoksyms.h at include/linux/export.h:81 3. compile with -j112This fails loudly, but then I do
4. uncomment the include for
generated/autoksyms.hatinclude/linux/export.h:81
A simpler workaround is simply:
touch include/generated/autoksyms.h
But hopefully the patch I just sent would fix it for good.
Nicolas
Quoted 11 lines · Jarod Wilson
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<----
Quoted 4 lines
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:
https://lkml.kernel.org/r/<[email protected]>
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
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?
Quoted 6 lines
Multi-threaded make vs. single-threaded doesn't matter, setting
CONFIG_BROKEN=yor '#CONFIG_MODVERSIONSis 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.
Likewise (ie, both the modules splat going away if doing a single make and being baffled, but more that a wee bit).
Paul Bolle
Quoted 17 lines · Paul Bolle
Quoted 11 lines · Jarod Wilson
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<----Quoted 4 lines
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.
Quoted 6 lines
I ran into a modules build printing over 100K ERROR lines a month ago:
https://lkml.kernel.org/r/<[email protected]>That had to do with setting
TRIM_UNUSED_KSYMSand so unsettingUNUSED_SYMBOLS, as far as I could tell. Did you perhaps also haveUNUSED_SYMBOLSunset when your modules build when splat?
I did indeed have CONFIG_TRIM_UNUSED_KSYMS=y and CONFIG_UNUSED_SYMBOLS unset.
Quoted 2 lines
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.
Quoted 3 lines
If so I might have run into your second issue a month ago already, which makes your bisect to commit
cd3caefb4663("Fix subtleCONFIG_MODVERSIONSproblems") 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.
Quoted 9 lines
Quoted 6 lines
Multi-threaded make vs. single-threaded doesn't matter, setting
CONFIG_BROKEN=yor '#CONFIG_MODVERSIONSis 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.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.
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 23 lines · Jarod Wilson
Quoted 22 lines · Paul Bolle
Quoted 11 lines · Jarod Wilson
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<----Quoted 4 lines
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:
Quoted 8 lines
Quoted 5 lines
That had to do with setting
TRIM_UNUSED_KSYMSand so unsettingUNUSED_SYMBOLS,
as far as I could tell. Did you perhaps also haveUNUSED_SYMBOLSunset when
your modules build when splat?I did indeed have
CONFIG_TRIM_UNUSED_KSYMS=yandCONFIG_UNUSED_SYMBOLSunset.
Just to confirm, with CONFIG_TRIM_UNUSED_KSYMS unset, the build behaves normally, no ERROR spew.
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 2 lines · Jarod Wilson
Just to confirm, with
CONFIG_TRIM_UNUSED_KSYMSunset, the build behaves normally, no ERROR spew.
And if MODVERSIONS is not set?
My current theory is that setting MODVERSIONS, somehow, hides the ERROR spew. Because that could explain your bisect. Linus' commit turns of MODVERSIONS the hard way. And, naturally, this theory fails if your .configs never had MODVERSIONS set in the first place.
I'm testing all this right now, but you probably command more powerful machines and could beat me in testing this theory.
Thanks,
Paul Bolle
Quoted 4 lines · Paul Bolle
My current theory is that setting MODVERSIONS, somehow, hides the ERROR spew. Because that could explain your bisect. Linus' commit turns of MODVERSIONS the hard way. And, naturally, this theory fails if your .configs never had MODVERSIONS set in the first place.
This theory appears to be correct!
It's getting late here so I won't be spending much time on this anymore. Perhaps you fancy looking into all this now. And, maybe, a new day will bring me the courage needed to dive into this.
Thanks,
Paul Bolle
Quoted 5 lines · Paul Bolle
Quoted 4 lines · Paul Bolle
My current theory is that setting MODVERSIONS, somehow, hides the ERROR spew. Because that could explain your bisect. Linus' commit turns of MODVERSIONS the hard way. And, naturally, this theory fails if your .configs never had MODVERSIONS set in the first place.
My config had MODVERSIONS set, yes.
Quoted 5 lines
This theory appears to be correct!
It's getting late here so I won't be spending much time on this anymore. Perhaps you fancy looking into all this now. And, maybe, a new day will bring me the courage needed to dive into this.
Done for the day here too, will continue prodding tomorrow.
Signature · 2 lines
Jarod Wilson [email protected]
[Added Nicolas, for whom this all might be painfully obvious.]
Quoted 1 line · Jarod Wilson
My config had MODVERSIONS set, yes.
For the record triggering this flood of ERRORs for undefined symbols that you ran into has been possible ever since TRIM_UNUSED_KSYMS was added to the tree (in v4.7). I just tested that.
Perhaps this is all documented somewhere. But even then it would be nice if the build would fail right at the start. Ie, the build probably should fail if one does "make bzImage" while having a .config with CONFIG_TRIM_UNUSED_KSYMS=y
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
Because it seems in that case the subsequent "make modules" will then end in this flood of ERRORs.
Paul Bolle
Quoted 9 lines · Paul Bolle
Perhaps this is all documented somewhere. But even then it would be nice if the build would fail right at the start. Ie, the build probably should fail if one does "make bzImage" while having a .config with
CONFIG_TRIM_UNUSED_KSYMS=y
CONFIG_MODULES=y
#CONFIG_MODVERSIONSis not setBecause it seems in that case the subsequent "make modules" will then end in this flood of ERRORs.
Or, alternatively, we could use something like the following hack to keep a two step build (ie, "make bzImage" and "make modules") do the right thing even if CONFING_MODVERSIONS is not set.
The hack was cobbled together with a fair amount of cargo-cult coding so perhaps a hunk or two aren't really needed. We'll see.
Paul Bolle
Makefile +1 -1
@@ -321,7 +321,7 @@ KBUILD_BUILTIN := 1 # make sure the checksums are up to date before we record them. ifeq ($(MAKECMDGOALS),modules) - KBUILD_BUILTIN := $(if $(CONFIG_MODVERSIONS),1) + KBUILD_BUILTIN := $(if $(or $(CONFIG_MODVERSIONS),$(CONFIG_TRIM_UNUSED_KSYMS)),1) endif # If we have "make <whatever> modules", compile modules
scripts/Makefile +3 -1
@@ -40,7 +40,9 @@ build_docproc: $(obj)/docproc build_check-lc_ctype: $(obj)/check-lc_ctype @: -subdir-$(CONFIG_MODVERSIONS) += genksyms +ifeq ($(or $(CONFIG_MODVERSIONS),$(CONFIG_TRIM_UNUSED_KSYMS)),y) +subdir-y += genksyms +endif subdir-y += mod subdir-$(CONFIG_SECURITY_SELINUX) += selinux subdir-$(CONFIG_DTC) += dtc
scripts/Makefile.build +2 -2
@@ -182,7 +182,7 @@ $(obj)/%.symtypes : $(src)/%.c FORCE quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ -ifndef CONFIG_MODVERSIONS +ifneq ($(if $(CONFIG_MODVERSIONS),1,$(if $(CONFIG_TRIM_UNUSED_KSYMS),1)),1) cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< else
@@ -358,7 +358,7 @@ $(obj)/%.s: $(src)/%.S FORCE quiet_cmd_as_o_S = AS $(quiet_modtag) $@ -ifndef CONFIG_MODVERSIONS +ifneq ($(if $(CONFIG_MODVERSIONS),1,$(if $(CONFIG_TRIM_UNUSED_KSYMS),1)),1) cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $< else
scripts/adjust_autoksyms.sh +1 -1
@@ -68,7 +68,7 @@ while read sym; do done >> "$new_ksyms_file" # Special case for modversions (see modpost.c) -if [ -n "$CONFIG_MODVERSIONS" ]; then +if [ -n "$CONFIG_MODVERSIONS" -o -n "$CONFIG_TRIM_UNUSED_KSYMS" ]; then echo "#define __KSYM_module_layout 1" >> "$new_ksyms_file" fi
Quoted 11 lines · Paul Bolle
Quoted 9 lines · Paul Bolle
Perhaps this is all documented somewhere. But even then it would be nice if the build would fail right at the start. Ie, the build probably should fail if one does "make bzImage" while having a .config with
CONFIG_TRIM_UNUSED_KSYMS=y
CONFIG_MODULES=y
#CONFIG_MODVERSIONSis not setBecause it seems in that case the subsequent "make modules" will then end in this flood of ERRORs.
Quoted 6 lines
Or, alternatively, we could use something like the following hack to keep a two step build (ie, "make bzImage" and "make modules") do the right thing even if
CONFING_MODVERSIONSis not set.The hack was cobbled together with a fair amount of cargo-cult coding so perhaps a hunk or two aren't really needed. We'll see.
OK I understand what the problem is. However most of those hunks below are definitely wrong. ;-)
I'm trying to determine the best way to fix it. Stay tuned.
Quoted 66 lines
Paul Bolle
Makefile +1
-1@@ -321,7 +321,7 @@ KBUILD_BUILTIN := 1 # make sure the checksums are up to date before we record them. ifeq ($(MAKECMDGOALS),modules) - KBUILD_BUILTIN := $(if $(CONFIG_MODVERSIONS),1) + KBUILD_BUILTIN := $(if $(or $(CONFIG_MODVERSIONS),$(CONFIG_TRIM_UNUSED_KSYMS)),1) endif # If we have "make <whatever> modules", compile modulesscripts/Makefile +3
-1@@ -40,7 +40,9 @@ build_docproc: $(obj)/docproc build_check-lc_ctype: $(obj)/check-lc_ctype @: -subdir-$(CONFIG_MODVERSIONS) += genksyms +ifeq ($(or $(CONFIG_MODVERSIONS),$(CONFIG_TRIM_UNUSED_KSYMS)),y) +subdir-y += genksyms +endif subdir-y += mod subdir-$(CONFIG_SECURITY_SELINUX) += selinux subdir-$(CONFIG_DTC) += dtcscripts/Makefile.build +2
-2@@ -182,7 +182,7 @@ $(obj)/%.symtypes : $(src)/%.c FORCE quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ -ifndef CONFIG_MODVERSIONS +ifneq ($(if $(CONFIG_MODVERSIONS),1,$(if $(CONFIG_TRIM_UNUSED_KSYMS),1)),1) cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< else@@ -358,7 +358,7 @@ $(obj)/%.s: $(src)/%.S FORCE quiet_cmd_as_o_S = AS $(quiet_modtag) $@ -ifndef CONFIG_MODVERSIONS +ifneq ($(if $(CONFIG_MODVERSIONS),1,$(if $(CONFIG_TRIM_UNUSED_KSYMS),1)),1) cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $< elsescripts/adjust_autoksyms.sh +1
-1@@ -68,7 +68,7 @@ while read sym; do done >> "$new_ksyms_file" # Special case for modversions (see modpost.c) -if [ -n "$CONFIG_MODVERSIONS" ]; then +if [ -n "$CONFIG_MODVERSIONS" -o -n "$CONFIG_TRIM_UNUSED_KSYMS" ]; then echo "#define __KSYM_module_layout 1" >> "$new_ksyms_file" fi
Quoted 2 lines · Nicolas Pitre
OK I understand what the problem is. However most of those hunks below are definitely wrong. ;-)
Probably. By now I've narrowed it down to just these two hunks:
scripts/Makefile +3 -1
@@ -40,7 +40,9 @@ build_docproc: $(obj)/docproc build_check-lc_ctype: $(obj)/check-lc_ctype @: -subdir-$(CONFIG_MODVERSIONS) += genksyms +ifeq ($(or $(CONFIG_MODVERSIONS),$(CONFIG_TRIM_UNUSED_KSYMS)),y) +subdir-y += genksyms +endif subdir-y += mod subdir-$(CONFIG_SECURITY_SELINUX) += selinux subdir-$(CONFIG_DTC) += dtc
scripts/adjust_autoksyms.sh +1 -1
@@ -68,7 +68,7 @@ while read sym; do done >> "$new_ksyms_file" # Special case for modversions (see modpost.c) -if [ -n "$CONFIG_MODVERSIONS" ]; then +if [ -n "$CONFIG_MODVERSIONS" -o -n "$CONFIG_TRIM_UNUSED_KSYMS" ]; then echo "#define __KSYM_module_layout 1" >> "$new_ksyms_file" fi
Quoted 1 line
I'm trying to determine the best way to fix it. Stay tuned.
Will do. I'm curious to see what a proper fix might look like.
Thanks,
Paul Bolle
Quoted 5 lines · Paul Bolle
Quoted 2 lines · Nicolas Pitre
OK I understand what the problem is. However most of those hunks below are definitely wrong. ;-)
Probably. By now I've narrowed it down to just these two hunks:
And they're both wrong. ;-) There is no relation between MODVERSIONS and TRIM_UNUSED_KSYMS.
Quoted 3 lines
Quoted 1 line
I'm trying to determine the best way to fix it. Stay tuned.
Will do. I'm curious to see what a proper fix might look like.
Here it is:
----- >8
Subject: kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled
When building a specific target such as bzImage, modules aren't normally built. However if CONFIG_TRIM_UNUSED_KSYMS is enabled, no built modules means none of the exported symbols are used and therefore they will all be trimmed away from the final kernel. A subsequent "make modules" will fail because modpost cannot find the needed symbols for those modules in the kernel binary.
Let's make sure modules are also built whenever CONFIG_TRIM_UNUSED_KSYMS is enabled and that the kernel binary is properly rebuilt accordingly.
Makefile +8 -1
@@ -607,6 +607,13 @@ else include/config/auto.conf: ; endif # $(dot-config) +# For the kernel to actually contain only the needed exported symbols, +# we have to build modules as well to determine what those symbols are. +# (this can be evaluated only once include/config/auto.conf has been included) +ifdef CONFIG_TRIM_UNUSED_KSYMS + KBUILD_MODULES := 1 +endif + # The all: target is the default when no target is given on the # command line. # This allow a user to issue only 'make' to build a kernel including modules
@@ -944,7 +951,7 @@ ifdef CONFIG_GDB_SCRIPTS endif ifdef CONFIG_TRIM_UNUSED_KSYMS $(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \ - "$(MAKE) KBUILD_MODULES=1 -f $(srctree)/Makefile vmlinux_prereq" + "$(MAKE) -f $(srctree)/Makefile vmlinux" endif # standalone target for easier testing
Jarod Wilson
Tested-byQuoted 27 lines · Nicolas Pitre
Quoted 5 lines · Paul Bolle
Quoted 2 lines · Nicolas Pitre
OK I understand what the problem is. However most of those hunks below are definitely wrong. ;-)
Probably. By now I've narrowed it down to just these two hunks:
And they're both wrong. ;-) There is no relation between MODVERSIONS and
TRIM_UNUSED_KSYMS.Quoted 3 lines
Quoted 1 line
I'm trying to determine the best way to fix it. Stay tuned.
Will do. I'm curious to see what a proper fix might look like.
Here it is:
----- >8
Subject: kbuild: fix building bzImage withCONFIG_TRIM_UNUSED_KSYMSenabledWhen building a specific target such as bzImage, modules aren't normally built. However if
CONFIG_TRIM_UNUSED_KSYMSis enabled, no built modules means none of the exported symbols are used and therefore they will all be trimmed away from the final kernel. A subsequent "make modules" will fail because modpost cannot find the needed symbols for those modules in the kernel binary.
Quoted 2 lines
Let's make sure modules are also built whenever
CONFIG_TRIM_UNUSED_KSYMSis enabled and that the kernel binary is properly rebuilt accordingly.
For my previously failing case, things behave again with this patch. Thanks much!
Signature · 2 lines
Jarod Wilson [email protected]