Messages in this thread | | | Subject | Re: [sched] c3a340f7e7: invalid_opcode:#[##] | From | Florian Fainelli <> | Date | Tue, 20 Oct 2020 16:39:38 -0700 |
| |
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
| |