Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1533461 > unrolled thread

Odd build breakage in 4.9-rc7

Back to article view | Back to linux.kernel

Contents

  Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-11-30 18:30 +0100
    Re: Odd build breakage in 4.9-rc7 Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-30 19:20 +0100
      Re: Odd build breakage in 4.9-rc7 Prarit Bhargava <prarit@redhat.com> - 2016-11-30 19:30 +0100
        Re: Odd build breakage in 4.9-rc7 Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-30 19:40 +0100
          Re: Odd build breakage in 4.9-rc7 Prarit Bhargava <prarit@redhat.com> - 2016-11-30 20:00 +0100
            Re: Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-11-30 20:10 +0100
            Re: Odd build breakage in 4.9-rc7 Linus Torvalds <torvalds@linux-foundation.org> - 2016-11-30 20:40 +0100
              Re: Odd build breakage in 4.9-rc7 Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-11-30 23:50 +0100
                Re: Odd build breakage in 4.9-rc7 Prarit Bhargava <prarit@redhat.com> - 2016-12-01 13:50 +0100
                Re: Odd build breakage in 4.9-rc7 Prarit Bhargava <prarit@redhat.com> - 2016-12-01 15:20 +0100
                  Re: Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-12-01 16:30 +0100
            Re: Odd build breakage in 4.9-rc7 Nicolas Pitre <nico@fluxnic.net> - 2016-12-01 00:20 +0100
    Re: Odd build breakage in 4.9-rc7 Paul Bolle <pebolle@tiscali.nl> - 2016-11-30 22:00 +0100
      Re: Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-11-30 22:10 +0100
        Re: Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-11-30 22:40 +0100
          Re: Odd build breakage in 4.9-rc7 Paul Bolle <pebolle@tiscali.nl> - 2016-11-30 22:50 +0100
            Re: Odd build breakage in 4.9-rc7 Paul Bolle <pebolle@tiscali.nl> - 2016-11-30 23:00 +0100
              Re: Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-12-01 00:50 +0100
                Re: Odd build breakage in 4.9-rc7 Paul Bolle <pebolle@tiscali.nl> - 2016-12-01 10:10 +0100
                  Re: Odd build breakage in 4.9-rc7 Paul Bolle <pebolle@tiscali.nl> - 2016-12-01 14:50 +0100
                    Re: Odd build breakage in 4.9-rc7 Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-12-01 18:50 +0100
                      Re: Odd build breakage in 4.9-rc7 Paul Bolle <pebolle@tiscali.nl> - 2016-12-01 21:20 +0100
                        Re: Odd build breakage in 4.9-rc7 Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-12-02 21:20 +0100
                          Re: Odd build breakage in 4.9-rc7 Jarod Wilson <jarod@redhat.com> - 2016-12-02 23:50 +0100

Page 1 of 2  [1] 2  Next page →

#1533461 — 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! ;)

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [next] | [standalone]

#1533487

On Wed, Nov 30, 2016 at 9:24 AM, Jarod Wilson <jarod@redhat.com> wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#1533491

On 11/30/2016 01:18 PM, Linus Torvalds wrote:
> On Wed, Nov 30, 2016 at 9:24 AM, Jarod Wilson <jarod@redhat.com> wrote:
>>
>> 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.
> 

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.

>               Linus
> 

[toc] | [prev] | [next] | [standalone]

#1533499

On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <prarit@redhat.com> wrote:
]>
> 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.

Ok, that at least makes some sense. The other blamed commit did not
seem to possibly make a difference.

> 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

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

[toc] | [prev] | [next] | [standalone]

#1533513

On 11/30/2016 01:36 PM, Linus Torvalds wrote:
> On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <prarit@redhat.com> wrote:
> ]>
>> 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.
> 
> Ok, that at least makes some sense. The other blamed commit did not
> seem to possibly make a difference.
> 
>> 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
> 
> 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.

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

[toc] | [prev] | [next] | [standalone]

#1533515

On 2016-11-30 1:50 PM, Prarit Bhargava wrote:
>
> On 11/30/2016 01:36 PM, Linus Torvalds wrote:
>> On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>> ]>
>>> 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.
>>
>> Ok, that at least makes some sense. The other blamed commit did not
>> seem to possibly make a difference.
>>
>>> 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
>>
>> 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.

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

9a6fb28a355d2609ace4dab4e6425442c647894d
3637efb00864f465baebd49464e58319fd295b65
ffb173e657fa8123bffa2a169e124b4bca0b5bc4

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

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

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [prev] | [next] | [standalone]

#1533531

On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#1533650

On Wed, 30 Nov 2016, Linus Torvalds wrote:

> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <prarit@redhat.com> wrote:
> >
> > 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.

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

Signed-off-by: Nicolas Pitre <nico@linaro.org>

diff --git a/Makefile b/Makefile
index 694111b43c..9f9c3b577c 100644
--- a/Makefile
+++ b/Makefile
@@ -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
 
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index ebced77deb..90a091b6ae 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -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

[toc] | [prev] | [next] | [standalone]

#1534065

On 11/30/2016 05:41 PM, Nicolas Pitre wrote:
> On Wed, 30 Nov 2016, Linus Torvalds wrote:
> 
>> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>>>
>>> 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. :)

> In other words, I can't reproduce regardless of the -j value I try.
> 
>> 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
> 

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.

[toc] | [prev] | [next] | [standalone]

#1534135

On 11/30/2016 05:41 PM, Nicolas Pitre wrote:
> On Wed, 30 Nov 2016, Linus Torvalds wrote:
> 
>> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>>>
>>> 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.
> 
>> 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.
> 
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
> 
> diff --git a/Makefile b/Makefile
> index 694111b43c..9f9c3b577c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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
>  
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index ebced77deb..90a091b6ae 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -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.

Tested-by: Prarit Bhargava <prarit@redhat.com>

P.

[toc] | [prev] | [next] | [standalone]

#1534194

On 2016-12-01 9:03 AM, Prarit Bhargava wrote:
>
>
> On 11/30/2016 05:41 PM, Nicolas Pitre wrote:
>> On Wed, 30 Nov 2016, Linus Torvalds wrote:
>>
>>> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>>>>
>>>> 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.
>>
>>> 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.
>>
>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>
>> diff --git a/Makefile b/Makefile
>> index 694111b43c..9f9c3b577c 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -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
>>
>> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>> index ebced77deb..90a091b6ae 100644
>> --- a/scripts/kconfig/Makefile
>> +++ b/scripts/kconfig/Makefile
>> @@ -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.
>
> Tested-by: Prarit Bhargava <prarit@redhat.com>

Looks good here as well, can do parallel make w/o reverting Tony's 
patches again.

Tested-by: Jarod Wilson <jarod@redhat.com>

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [prev] | [next] | [standalone]

#1533669

On Wed, 30 Nov 2016, Prarit Bhargava wrote:

> 
> 
> On 11/30/2016 01:36 PM, Linus Torvalds wrote:
> > On Wed, Nov 30, 2016 at 10:28 AM, Prarit Bhargava <prarit@redhat.com> wrote:
> > ]>
> >> 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.
> > 
> > Ok, that at least makes some sense. The other blamed commit did not
> > seem to possibly make a difference.
> > 
> >> 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
> > 
> > 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

A simpler workaround is simply:

	touch include/generated/autoksyms.h

But hopefully the patch I just sent would fix it for good.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1533565

On Wed, 2016-11-30 at 12:24 -0500, Jarod Wilson wrote:
> 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.

I ran into a modules build printing over 100K ERROR lines a month ago:
    https://lkml.kernel.org/r/<1478165881-9263-1-git-send-email-pebolle@tiscali.nl>

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?

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

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


Paul Bolle

[toc] | [prev] | [next] | [standalone]

#1533576

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:
>>
>> ----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.
>
> I ran into a modules build printing over 100K ERROR lines a month ago:
>     https://lkml.kernel.org/r/<1478165881-9263-1-git-send-email-pebolle@tiscali.nl>
>
> 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?

I did indeed have CONFIG_TRIM_UNUSED_KSYMS=y and CONFIG_UNUSED_SYMBOLS 
unset.

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

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [prev] | [next] | [standalone]

#1533591

On 2016-11-30 4:07 PM, Jarod Wilson wrote:
> 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:
>>>
>>> ----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.
>>
>> I ran into a modules build printing over 100K ERROR lines a month ago:
>>
>> https://lkml.kernel.org/r/<1478165881-9263-1-git-send-email-pebolle@tiscali.nl>
>>
>>
>> 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?
>
> I did indeed have CONFIG_TRIM_UNUSED_KSYMS=y and CONFIG_UNUSED_SYMBOLS
> unset.

Just to confirm, with CONFIG_TRIM_UNUSED_KSYMS unset, the build behaves 
normally, no ERROR spew.

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [prev] | [next] | [standalone]

#1533598

On Wed, 2016-11-30 at 16:35 -0500, Jarod Wilson wrote:
> Just to confirm, with CONFIG_TRIM_UNUSED_KSYMS unset, 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

[toc] | [prev] | [next] | [standalone]

#1533616

On Wed, 2016-11-30 at 22:42 +0100, Paul Bolle wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#1533686

On 2016-11-30 4:57 PM, Paul Bolle wrote:
> On Wed, 2016-11-30 at 22:42 +0100, Paul Bolle wrote:
>> 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.

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

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [prev] | [next] | [standalone]

#1533906

[Added Nicolas, for whom this all might be painfully obvious.]

On Wed, 2016-11-30 at 18:40 -0500, Jarod Wilson wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#1534099

On Thu, 2016-12-01 at 10:01 +0100, Paul Bolle wrote:
> 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. 

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

diff --git a/Makefile b/Makefile
index 694111b43cf8..5820f803ca64 100644
--- a/Makefile
+++ b/Makefile
@@ -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
diff --git a/scripts/Makefile b/scripts/Makefile
index 1d80897a9644..f23e5c4f2496 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -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
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 7675d11ee65e..50ce2cf86b7c 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -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
diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
index 8dc1918b6783..7525da1cc2f7 100755
--- a/scripts/adjust_autoksyms.sh
+++ b/scripts/adjust_autoksyms.sh
@@ -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
 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web