Building a custom kernel with 5.8 rc2 fails with error

[stan]

I sent the message below to the kernel list on Wednesday, and have not
seen it on the list yet.  So I am copying Justin, who I expect would be
the person that would answer this question if possible, and resending
it in case it somehow got lost in the data center move.

Hi,

I am trying to build a custom kernel from the src.rpm for 5.8.0.0.rc2
(kernel-5.8.0-0.rc2.20200623gitdd0d718152e4.1.fc33.src.rpm) on FC31, and
it fails with the following error.  I've tried two candidates so far,
and both failed (0622, 0623).  The same configuration works on 5.7
kernels.

Can you provide any insight, or a workaround?


In file included from ./arch/x86/include/asm/atomic.h:5,
                 from ./include/linux/atomic.h:7,
                 from ./include/linux/llist.h:51,
                 from ./include/linux/irq_work.h:5,
                 from kernel/smp.c:10:
kernel/smp.c: In function 'smp_init':
./include/linux/compiler.h:392:38: error: call to
      '__compiletime_assert_156' declared with attribute error:
      BUILD_BUG_ON failed: offsetof(struct task_struct,
      wake_entry_type) - offsetof(struct task_struct, wake_entry) !=
      offsetof(struct __call_single_data, flags) - offsetof(struct
      __call_single_data, llist) 392 |  _compiletime_assert(condition,
      msg, __compiletime_assert_, __COUNTER__) |
                    ^ ./include/linux/compiler.h:373:4: note: in
      definition of macro '__compiletime_assert' 373 |    prefix ##
      suffix();    \ |    ^~~~~~ ./include/linux/compiler.h:392:2:
      note: in expansion of macro '_compiletime_assert' 392 |
      _compiletime_assert(condition, msg, __compiletime_assert_,
      __COUNTER__) |  ^~~~~~~~~~~~~~~~~~~
      ./include/linux/build_bug.h:39:37: note: in expansion of macro
      'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg)
      compiletime_assert(!(cond), msg) |
           ^~~~~~~~~~~~~~~~~~ ./include/linux/build_bug.h:50:2: note:
      in expansion of macro 'BUILD_BUG_ON_MSG' 50 |
      BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) |
       ^~~~~~~~~~~~~~~~ kernel/smp.c:687:2: note: in expansion of macro
      'BUILD_BUG_ON' 687 |  BUILD_BUG_ON(offsetof(struct task_struct,
      wake_entry_type) - offsetof(struct task_struct, wake_entry) != |
      ^~~~~~~~~~~~ make[1]: *** [scripts/Makefile.build:281:
      kernel/smp.o] Error 1 make[1]: *** Waiting for unfinished jobs....

[Justin Forbes]

On Fri, Jun 26, 2020 at 12:15 PM stan <upaitag(a)zoho.com&gt; wrote:
>  I sent the message below to the kernel list on Wednesday, and have not
>  seen it on the list yet.  So I am copying Justin, who I expect would be
>  the person that would answer this question if possible, and resending
>  it in case it somehow got lost in the data center move.
>
>  Hi,
>
>  I am trying to build a custom kernel from the src.rpm for 5.8.0.0.rc2
>  (kernel-5.8.0-0.rc2.20200623gitdd0d718152e4.1.fc33.src.rpm) on FC31, and
>  it fails with the following error.  I've tried two candidates so far,
>  and both failed (0622, 0623).  The same configuration works on 5.7
>  kernels.
>
>  Can you provide any insight, or a workaround?
>  
What changes are you making to your custom build?  This is not
something we are hitting in rawhide.

Justin

>
> In file included from ./arch/x86/include/asm/atomic.h:5,
>                  from ./include/linux/atomic.h:7,
>                  from ./include/linux/llist.h:51,
>                  from ./include/linux/irq_work.h:5,
>                  from kernel/smp.c:10:
> kernel/smp.c: In function 'smp_init':
> ./include/linux/compiler.h:392:38: error: call to
>       '__compiletime_assert_156' declared with attribute error:
>       BUILD_BUG_ON failed: offsetof(struct task_struct,
>       wake_entry_type) - offsetof(struct task_struct, wake_entry) !=
>       offsetof(struct __call_single_data, flags) - offsetof(struct
>       __call_single_data, llist) 392 |  _compiletime_assert(condition,
>       msg, __compiletime_assert_, __COUNTER__) |
>                     ^ ./include/linux/compiler.h:373:4: note: in
>       definition of macro '__compiletime_assert' 373 |    prefix ##
>       suffix();    \ |    ^~~~~~ ./include/linux/compiler.h:392:2:
>       note: in expansion of macro '_compiletime_assert' 392 |
>       _compiletime_assert(condition, msg, __compiletime_assert_,
>       __COUNTER__) |  ^~~~~~~~~~~~~~~~~~~
>       ./include/linux/build_bug.h:39:37: note: in expansion of macro
>       'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg)
>       compiletime_assert(!(cond), msg) |
>            ^~~~~~~~~~~~~~~~~~ ./include/linux/build_bug.h:50:2: note:
>       in expansion of macro 'BUILD_BUG_ON_MSG' 50 |
>       BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) |
>        ^~~~~~~~~~~~~~~~ kernel/smp.c:687:2: note: in expansion of macro
>       'BUILD_BUG_ON' 687 |  BUILD_BUG_ON(offsetof(struct task_struct,
>       wake_entry_type) - offsetof(struct task_struct, wake_entry) != |
>       ^~~~~~~~~~~~ make[1]: *** [scripts/Makefile.build:281:
>       kernel/smp.o] Error 1 make[1]: *** Waiting for unfinished jobs....

[stan]

On Fri, 26 Jun 2020 12:17:29 -0500
Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:

>  What changes are you making to your custom build?  This is not
>  something we are hitting in rawhide. 
Extensive.  It is tuned for my hardware, and turns off anything that
isn't necessary.  But I didn't change any options from what worked
with 5.7.  There were new configuration options with 5.8 that I left
turned off; maybe it was one of them, though none of them had anything
to do with smp that I could determine.

I was afraid it might be something like this, but was hoping that you
would be aware of some obvious change to the kernel that would cause
this.  Could it be related to the switch to the later version of gcc in
rawhide?  i.e.  new flags not recognized by my older version of gcc are
causing the problem.

[Justin Forbes]

On Fri, Jun 26, 2020 at 12:38 PM stan <upaitag(a)zoho.com&gt; wrote:
>  On Fri, 26 Jun 2020 12:17:29 -0500
>  Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>
>  > What changes are you making to your custom build?  This is not
>  > something we are hitting in rawhide.
>
>  Extensive.  It is tuned for my hardware, and turns off anything that
>  isn't necessary.  But I didn't change any options from what worked
>  with 5.7.  There were new configuration options with 5.8 that I left
>  turned off; maybe it was one of them, though none of them had anything
>  to do with smp that I could determine.
>
>  I was afraid it might be something like this, but was hoping that you
>  would be aware of some obvious change to the kernel that would cause
>  this.  Could it be related to the switch to the later version of gcc in
>  rawhide?  i.e.  new flags not recognized by my older version of gcc are
>  causing the problem. 

I am not sure, I haven't tried building on f31, but it does build fine
on f32.  Given that the kernels gcc targets are much lower than what
we are shipping anywhere in Fedora, I would not expect that to be the
case, but it could be a bug.

Justin

[stan]

On Fri, 26 Jun 2020 13:36:26 -0500
Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:

>  I am not sure, I haven't tried building on f31, but it does build
> fine
>  on f32.  Given that the kernels gcc targets are much lower than what
>  we are shipping anywhere in Fedora, I would not expect that to be the
>  case, but it could be a bug. 
Thanks, a bug after all this time, while possible, seems unlikely; I'll
just keep plugging away at it, trying with newer kernel packages, and
by changing the new configuration options in various patterns.  Maybe
I'll do some diffs of the 5.7 and 5.8 files that are implicated to see
if anything has changed.

[Ondrej Mosnacek]

Hi stan,

On Fri, Jun 26, 2020 at 9:12 PM stan <upaitag(a)zoho.com&gt; wrote:
>  On Fri, 26 Jun 2020 13:36:26 -0500
>  Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>
>  > I am not sure, I haven't tried building on f31, but it does build fine
>  > on f32.  Given that the kernels gcc targets are much lower than what
>  > we are shipping anywhere in Fedora, I would not expect that to be the
>  > case, but it could be a bug.
>
>  Thanks, a bug after all this time, while possible, seems unlikely; I'll
>  just keep plugging away at it, trying with newer kernel packages, and
>  by changing the new configuration options in various patterns.  Maybe
>  I'll do some diffs of the 5.7 and 5.8 files that are implicated to see
>  if anything has changed. 
Apparently you are not the only one hitting this problem:
https://lore.kernel.org/lkml/[e-mail]/
Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around
it (but hopefully the guys will fix it in a better way eventually).

It wasn't really hard to find the thread:
1. `git blame kernel/smp.c` to find which commit introduced the lines
that throw the error.
2. The commit message has a helpful link to the original patch
submission in the LKML archives.
3. Clicked the third reply (longest subthread) to the patch itself and
read the rest of the replies in the thread.
4. Bingo ;-)

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

[stan]

On Fri, 26 Jun 2020 21:34:27 +0200
Ondrej Mosnacek <omosnace(a)redhat.com&gt; wrote:

>  Apparently you are not the only one hitting this problem:
>  https://lore.kernel.org/lkml/[e-mail]/
>  Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around
>  it (but hopefully the guys will fix it in a better way eventually).
>  
>  It wasn't really hard to find the thread:
>  1. `git blame kernel/smp.c` to find which commit introduced the lines
>  that throw the error.
>  2. The commit message has a helpful link to the original patch
>  submission in the LKML archives.
>  3. Clicked the third reply (longest subthread) to the patch itself and
>  read the rest of the replies in the thread.
>  4. Bingo ;-) 
Thank you!  I never even thought to do a search.  I just presumed it
was something I had done, especially since the rawhide builds were
succeeding (which in fact I had, just a long time ago).  They must have
that CONFIG_GCC_PLUGIN_RANDSTRUCT turned off.

[stan]

On Fri, 26 Jun 2020 21:34:27 +0200
Ondrej Mosnacek <omosnace(a)redhat.com&gt; wrote:

>  Apparently you are not the only one hitting this problem:
>  https://lore.kernel.org/lkml/[e-mail]/
>  Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around
>  it (but hopefully the guys will fix it in a better way eventually).
>  
>  It wasn't really hard to find the thread:
>  1. `git blame kernel/smp.c` to find which commit introduced the lines
>  that throw the error.
>  2. The commit message has a helpful link to the original patch
>  submission in the LKML archives.
>  3. Clicked the third reply (longest subthread) to the patch itself and
>  read the rest of the replies in the thread.
>  4. Bingo ;-) 
And like others in the above thread, when I turn off
CONFIG_GCC_PLUGIN_RANDSTRUCT, compilation succeeds.