]> git.karo-electronics.de Git - karo-tx-linux.git/commit
init: scream bloody murder if interrupts are enabled too early
authorSteven Rostedt <rostedt@goodmis.org>
Tue, 26 Mar 2013 23:25:09 +0000 (10:25 +1100)
committerStephen Rothwell <sfr@canb.auug.org.au>
Thu, 4 Apr 2013 06:12:31 +0000 (17:12 +1100)
commit9e46a2972aba4eb163bfc974370f4eeae84d602c
treeeea0503423003b8c8cf54918772ca40da33863c8
parent9652ab3642470bb997f437cf5dffd015ee5d9eba
init: scream bloody murder if interrupts are enabled too early

As I was testing a lot of my code recently, and having several
"successes", I accidentally noticed in the dmesg this little line:

[    0.000000] start_kernel(): bug: interrupts were enabled *very* early, fixing it

Sure enough, one of my patches two commits ago enabled interrupts early.
The sad part here is that I never noticed it, and I ran several tests with
ktest too, and ktest did not notice this line.

What ktest looks for (and so does many other automated testing scripts) is
a back trace produced by a WARN_ON() or BUG().  As a back trace was never
produced, my buggy patch could have slipped into linux-next, or even
worse, mainline.

Adding a WARN(!irqs_disabled()) makes this bug a little more obvious:

[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] Memory: 2003252k/2054848k available (4857k kernel code, 460k absent, 51136k reserved, 6210k data, 1096k init)
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /home/rostedt/work/git/linux-trace.git/init/main.c:543 start_kernel+0x21e/0x415()
[    0.000000] Hardware name: To Be Filled By O.E.M.
[    0.000000] Interrupts were enabled *very* early, fixing it
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper/0 Not tainted 3.8.0-test+ #286
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff81037b79>] warn_slowpath_common+0x83/0x9b
[    0.000000]  [<ffffffff81037c34>] warn_slowpath_fmt+0x46/0x48
[    0.000000]  [<ffffffff81ae4a39>] start_kernel+0x21e/0x415
[    0.000000]  [<ffffffff81ae4623>] ? repair_env_string+0x56/0x56
[    0.000000]  [<ffffffff81ae4312>] x86_64_start_reservations+0x10e/0x112
[    0.000000]  [<ffffffff81ae4120>] ? early_idt_handlers+0x120/0x120
[    0.000000]  [<ffffffff81ae4418>] x86_64_start_kernel+0x102/0x111
[    0.000000] ---[ end trace 007d8b0491b4f5d8 ]---
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] NR_IRQS:4352 nr_irqs:712 16
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled, bootconsole disabled

Do you see it?

The original version of this patch just slapped a WARN_ON() in there and
kept the printk().  Ard van Breemen suggested using the WARN() interface,
which makes the code a bit cleaner.

Also, while examining other warnings in init/main.c, I found two other
locations that deserve a bloody murder scream if their conditions are hit,
and updated them accordingly.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Ard van Breemen <ard@telegraafnet.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
init/main.c