linux-kernel - BUG: spinlock bad magic on CPU#0, migration/0/9

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150212003430.GA28656@linux.vnet.ibm.com>
Date:	Wed, 11 Feb 2015 16:34:30 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	linux-kernel@...r.kernel.org
Cc:	dave@...olabs.net, waiman.long@...com, peterz@...radead.org,
	oleg@...hat.com, raghavendra.kt@...ux.vnet.ibm.com
Subject: BUG: spinlock bad magic on CPU#0, migration/0/9

Hello!

Did an earlier-than-usual port of v3.21 patches to post-v3.19, and
hit the following on x86_64.  This happened after about 15 minutes of
rcutorture.  In contrast, I have been doing successful 15-hour runs
on v3.19.  I will check reproducibility and try to narrow it down.
Might this be a duplicate of the bug that Raghavendra posted a fix for?

Anyway, this was on 3e8c04eb1174 (Merge branch 'for-3.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata).

[  837.287011] BUG: spinlock bad magic on CPU#0, migration/0/9
[  837.287013]  lock: 0xffff88001ea0fe80, .magic: ffffffff, .owner:  gî<81>ÿÿÿÿ/0, .owner_cpu: -42
[  837.287013] CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0+ #1
[  837.287013] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[  837.287013]  ffff88001ea0fe80 ffff88001ea0bc78 ffffffff818f6f4b ffffffff810a5a51
[  837.287013]  ffffffff81e500e0 ffff88001ea0bc98 ffffffff818f3755 ffff88001ea0fe80
[  837.287013]  ffffffff81ca4396 ffff88001ea0bcb8 ffffffff818f377b ffff88001ea0fe80
[  837.287013] Call Trace:
[  837.287013]  [<ffffffff818f6f4b>] dump_stack+0x45/0x57
[  837.287013]  [<ffffffff810a5a51>] ? console_unlock+0x1f1/0x4c0
[  837.287013]  [<ffffffff818f3755>] spin_dump+0x8b/0x90
[  837.287013]  [<ffffffff818f377b>] spin_bug+0x21/0x26
[  837.287013]  [<ffffffff8109923c>] do_raw_spin_unlock+0x5c/0xa0
[  837.287013]  [<ffffffff81902587>] _raw_spin_unlock_irqrestore+0x27/0x50
[  837.287013]  [<ffffffff8108f0a1>] complete+0x41/0x50
[  837.287013]  [<ffffffff810ebb15>] cpu_stop_signal_done+0x25/0x30
[  837.287013]  [<ffffffff810ebf66>] cpu_stopper_thread+0x86/0x100
[  837.287013]  [<ffffffff810ebc73>] ? cpu_stop_should_run+0x23/0x50
[  837.287013]  [<ffffffff81902591>] ? _raw_spin_unlock_irqrestore+0x31/0x50
[  837.287013]  [<ffffffff8109420d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[  837.287013]  [<ffffffff810942dd>] ? trace_hardirqs_on+0xd/0x10
[  837.287013]  [<ffffffff810732a3>] smpboot_thread_fn+0x143/0x1b0
[  837.287013]  [<ffffffff81073160>] ? SyS_setgroups+0x150/0x150
[  837.287013]  [<ffffffff8106f438>] kthread+0xe8/0x100
[  837.287013]  [<ffffffff8106f350>] ? kthread_create_on_node+0x220/0x220
[  837.287013]  [<ffffffff81902dac>] ret_from_fork+0x7c/0xb0
[  837.287013]  [<ffffffff8106f350>] ? kthread_create_on_node+0x220/0x220

Things went downhill from there.  ;-)

This affected only one of my 16 test scenarios.

							Thanx, Paul

View attachment ".config" of type "text/plain" (97522 bytes)