linux-kernel - Re: [sched] c3a340f7e7: invalid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Oct 2020 16:39:38 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        kernel test robot <lkp@...el.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        lkp@...ts.01.org, keescook@...omium.org, hjl.tools@...il.com,
        linux@...musvillemoes.dk
Subject: Re: [sched] c3a340f7e7: invalid_opcode:#[##]

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