lkml.org 
[lkml]   [2020]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [sched] c3a340f7e7: invalid_opcode:#[##]
From
Date
On 6/30/20 7:49 AM, Peter Zijlstra wrote:
> On Tue, Jun 30, 2020 at 02:46:28PM +0200, Peter Zijlstra wrote:
>> On Mon, Jun 29, 2020 at 08:31:27AM +0800, kernel test robot wrote:
>>> Greeting,
>>>
>>> FYI, we noticed the following commit (built with gcc-4.9):
>>>
>>> commit: c3a340f7e7eadac7662ab104ceb16432e5a4c6b2 ("sched: Have sched_class_highest define by vmlinux.lds.h")
>>
>>> [ 1.840970] kernel BUG at kernel/sched/core.c:6652!
>>
>> W T H
>>
>> $ readelf -Wa defconfig-build/vmlinux | grep sched_class
>> 62931: c1e62d20 0 NOTYPE GLOBAL DEFAULT 2 __begin_sched_classes
>> 65736: c1e62f40 96 OBJECT GLOBAL DEFAULT 2 stop_sched_class
>> 71813: c1e62dc0 96 OBJECT GLOBAL DEFAULT 2 fair_sched_class
>> 78689: c1e62d40 96 OBJECT GLOBAL DEFAULT 2 idle_sched_class
>> 78953: c1e62fa0 0 NOTYPE GLOBAL DEFAULT 2 __end_sched_classes
>> 79090: c1e62e40 96 OBJECT GLOBAL DEFAULT 2 rt_sched_class
>> 79431: c1e62ec0 96 OBJECT GLOBAL DEFAULT 2 dl_sched_class
>>
>> $ printf "%d\n" $((0xc1e62dc0 - 0xc1e62d40))
>> 128
>>
>> So even though the object is 96 bytes in size, has an explicit 32 byte
>> alignment, the array ends up with a stride of 128 bytes !?!?!
>>
>> Consistently so with GCC-4.9. Any other GCC I tried does the sane thing.
>>
>> Full patch included below.
>>
>> Anybody any clue wth 4.9 is doing crazy things like this?
>>
>> ---
>
> This seems to make everything work, it builds and boots for 4.9 and
> builds x86_64-defconfig with clang11 (just to check a !GCC compiler).

Hi Peter,

This patch causes all files under kernel/sched/* that include sched.h to
be rebuilt whenever the value of CONFIG_BLK_DEV_INITRD. There are at
least two build systems (buildroot and OpenWrt) that toggle this
configuration value in order to produce a kernel image without an
initramfs, and one with.

On ARM we get all of these to be needlessly rebuilt:

CC kernel/sched/core.o
CC kernel/sched/loadavg.o
CC kernel/sched/clock.o
CC kernel/sched/cputime.o
CC kernel/sched/idle.o
CC kernel/sched/fair.o
CC kernel/sched/rt.o
CC kernel/sched/deadline.o
CC kernel/sched/wait.o
CC kernel/sched/wait_bit.o
CC kernel/sched/swait.o
CC kernel/sched/completion.o
CC kernel/sched/cpupri.o
CC kernel/sched/cpudeadline.o
CC kernel/sched/topology.o
CC kernel/sched/stop_task.o
CC kernel/sched/pelt.o
CC kernel/sched/debug.o
CC kernel/sched/cpufreq.o
CC kernel/sched/membarrier.o

Short of moving the STRUCT_ALIGNMENT to a separate header that would not
be subject to any configuration key change, can you think of a good way
to avoid these rebuilds, including for architectures like ARM that ship
their own vmlinux.lds.h? I would not say this is a bug, but it is
definitively an inconvenience.

Thanks!
--
Florian

\
 
 \ /
  Last update: 2020-10-21 01:40    [W:0.235 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site