Paul E. McKenney
cd95851785
rcu: fix classic RCU locking cleanup lockdep problem
On Fri, Aug 15, 2008 at 04:24:30PM +0200, Ingo Molnar wrote:
>
> Paul,
>
> one of your two recent RCU patches caused this lockdep splat in -tip
> testing:
>
> ------------------->
> Brought up 2 CPUs
> Total of 2 processors activated (6850.87 BogoMIPS).
> PM: Adding info for No Bus:platform
> khelper used greatest stack depth: 3124 bytes left
>
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.27-rc3-tip #1
> ---------------------------------
> inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> ksoftirqd/0/4 [HC0[0]:SC1[1]:HE1:SE0] takes:
> (&rcu_ctrlblk.lock){-+..}, at: [<c016d91c>] __rcu_process_callbacks+0x1ac/0x1f0
> {softirq-on-W} state was registered at:
> [<c01528e4>] __lock_acquire+0x3f4/0x5b0
> [<c0152b29>] lock_acquire+0x89/0xc0
> [<c076142b>] _spin_lock+0x3b/0x70
> [<c016d649>] rcu_init_percpu_data+0x29/0x80
> [<c075e43f>] rcu_cpu_notify+0xaf/0xd0
> [<c076458d>] notifier_call_chain+0x2d/0x60
> [<c0145ede>] __raw_notifier_call_chain+0x1e/0x30
> [<c075db29>] _cpu_up+0x79/0x110
> [<c075dc0d>] cpu_up+0x4d/0x70
> [<c0a769e1>] kernel_init+0xb1/0x200
> [<c01048a3>] kernel_thread_helper+0x7/0x10
> [<ffffffff>] 0xffffffff
> irq event stamp: 14
> hardirqs last enabled at (14): [<c01534db>] trace_hardirqs_on+0xb/0x10
> hardirqs last disabled at (13): [<c014dbeb>] trace_hardirqs_off+0xb/0x10
> softirqs last enabled at (0): [<c012b186>] copy_process+0x276/0x1190
> softirqs last disabled at (11): [<c0105c0a>] call_on_stack+0x1a/0x30
>
> other info that might help us debug this:
> no locks held by ksoftirqd/0/4.
>
> stack backtrace:
> Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.27-rc3-tip #1
> [<c01504dc>] print_usage_bug+0x16c/0x1b0
> [<c0152455>] mark_lock+0xa75/0xb10
> [<c0108b75>] ? sched_clock+0x15/0x30
> [<c015289d>] __lock_acquire+0x3ad/0x5b0
> [<c0152b29>] lock_acquire+0x89/0xc0
> [<c016d91c>] ? __rcu_process_callbacks+0x1ac/0x1f0
> [<c076142b>] _spin_lock+0x3b/0x70
> [<c016d91c>] ? __rcu_process_callbacks+0x1ac/0x1f0
> [<c016d91c>] __rcu_process_callbacks+0x1ac/0x1f0
> [<c016d986>] rcu_process_callbacks+0x26/0x50
> [<c0132305>] __do_softirq+0x95/0x120
> [<c0132270>] ? __do_softirq+0x0/0x120
> [<c0105c0a>] call_on_stack+0x1a/0x30
> [<c0132426>] ? ksoftirqd+0x96/0x110
> [<c0132390>] ? ksoftirqd+0x0/0x110
> [<c01411f7>] ? kthread+0x47/0x80
> [<c01411b0>] ? kthread+0x0/0x80
> [<c01048a3>] ? kernel_thread_helper+0x7/0x10
> =======================
> calling init_cpufreq_transition_notifier_list+0x0/0x20
> initcall init_cpufreq_transition_notifier_list+0x0/0x20 returned 0 after 0 msecs
> calling net_ns_init+0x0/0x190
> net_namespace: 676 bytes
> initcall net_ns_init+0x0/0x190 returned 0 after 0 msecs
> calling cpufreq_tsc+0x0/0x20
> initcall cpufreq_tsc+0x0/0x20 returned 0 after 0 msecs
> calling reboot_init+0x0/0x20
> initcall reboot_init+0x0/0x20 returned 0 after 0 msecs
> calling print_banner+0x0/0x10
> Booting paravirtualized kernel on bare hardware
>
> <-----------------------
>
> my guess is on:
>
> commit 1f7b94cd3d
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Tue Aug 5 09:21:44 2008 -0700
>
> rcu: classic RCU locking and memory-barrier cleanups
>
> Ingo
Fixes a problem detected by lockdep in which rcu->lock was acquired
both in irq context and in process context, but without disabling from
process context.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-17 17:38:01 +02:00
..
2008-08-05 14:33:47 -07:00
2008-07-26 12:00:04 -07:00
2008-07-26 16:40:33 +02:00
2008-07-28 23:32:00 +02:00
2008-07-25 10:53:47 -07:00
2008-05-17 03:30:23 -04:00
2008-08-01 12:15:16 -04:00
2008-08-01 12:15:03 -04:00
2008-08-04 06:13:50 -04:00
2008-06-27 18:09:16 +02:00
2008-07-24 10:47:22 -07:00
2008-07-30 09:41:44 -07:00
2008-07-28 23:32:00 +02:00
2008-07-30 09:41:44 -07:00
2008-07-25 10:53:47 -07:00
2008-08-05 14:33:49 -07:00
2008-07-26 20:53:20 -04:00
2008-08-01 12:01:11 -07:00
2008-07-28 16:30:21 -07:00
2008-06-23 13:31:15 +02:00
2008-07-15 21:55:59 +02:00
2008-07-25 10:53:27 -07:00
2008-07-23 11:18:28 +02:00
2008-07-26 12:00:04 -07:00
2008-08-01 08:39:35 -05:00
2008-07-25 10:53:28 -07:00
2008-07-25 10:53:30 -07:00
2008-07-26 12:00:09 -07:00
2008-06-24 01:28:20 +02:00
2008-06-24 01:28:20 +02:00
2008-07-14 14:55:13 -07:00
2008-07-29 00:07:55 +02:00
2008-07-30 09:41:45 -07:00
2008-07-28 12:16:31 +10:00
2008-05-16 16:53:35 +02:00
2008-07-28 18:12:36 +02:00
2008-07-25 10:53:37 -07:00
2008-07-25 10:53:37 -07:00
2008-07-25 10:53:29 -07:00
2008-07-25 10:53:47 -07:00
2008-07-25 10:53:45 -07:00
2008-08-05 14:33:50 -07:00
2008-05-24 18:49:22 +02:00
2008-07-25 10:53:38 -07:00
2008-07-30 09:41:45 -07:00
2008-07-25 10:53:27 -07:00
2008-07-26 12:00:09 -07:00
2008-08-17 17:38:01 +02:00
2008-07-15 14:12:03 -07:00
2008-08-15 17:54:40 +02:00
2008-07-16 00:29:07 +02:00
2008-06-26 09:24:33 +02:00
2008-08-05 14:33:46 -07:00
2008-07-25 10:53:36 -07:00
2008-07-30 09:41:43 -07:00
2008-07-21 21:55:02 -07:00
2008-07-14 12:19:13 +02:00
2008-06-06 15:19:28 +02:00
2008-06-06 15:19:44 +02:00
2008-06-27 14:31:31 +02:00
2008-07-23 19:36:53 -07:00
2008-06-27 14:31:47 +02:00
2008-05-05 23:56:17 +02:00
2008-07-24 12:53:51 -07:00
2008-07-04 12:50:23 +02:00
2008-08-04 17:16:20 -07:00
2008-08-05 14:33:47 -07:00
2008-07-26 12:00:09 -07:00
2008-07-26 12:00:04 -07:00
2008-07-26 12:00:04 -07:00
2008-07-26 12:00:04 -07:00
2008-05-23 20:39:40 +02:00
2008-06-30 09:20:55 +02:00
2008-07-28 12:16:30 +10:00
2008-07-25 11:35:41 -07:00
2008-07-26 12:00:04 -07:00
2008-07-25 10:53:45 -07:00
2008-07-27 09:45:34 -07:00
2008-07-25 10:53:47 -07:00
2008-05-02 16:18:42 -07:00
2008-05-02 16:18:42 -07:00
2008-07-14 16:06:58 -07:00
2008-07-27 16:12:28 -07:00
2008-07-30 09:41:47 -07:00