)]}'
{
  "commit": "cd95851785bcfe95fdf73689e8ecb5a1c5959231",
  "tree": "701d419396d1cc990bad624e7b9cdc867a318693",
  "parents": [
    "5802294f1b1895ee19a3d0ae72805da453afb9de"
  ],
  "author": {
    "name": "Paul E. McKenney",
    "email": "paulmck@linux.vnet.ibm.com",
    "time": "Sun Aug 17 07:37:15 2008 -0700"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Sun Aug 17 17:38:01 2008 +0200"
  },
  "message": "rcu: fix classic RCU locking cleanup lockdep problem\n\nOn Fri, Aug 15, 2008 at 04:24:30PM +0200, Ingo Molnar wrote:\n\u003e\n\u003e Paul,\n\u003e\n\u003e one of your two recent RCU patches caused this lockdep splat in -tip\n\u003e testing:\n\u003e\n\u003e -------------------\u003e\n\u003e Brought up 2 CPUs\n\u003e Total of 2 processors activated (6850.87 BogoMIPS).\n\u003e PM: Adding info for No Bus:platform\n\u003e khelper used greatest stack depth: 3124 bytes left\n\u003e\n\u003e \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\u003e [ INFO: inconsistent lock state ]\n\u003e 2.6.27-rc3-tip #1\n\u003e ---------------------------------\n\u003e inconsistent {softirq-on-W} -\u003e {in-softirq-W} usage.\n\u003e ksoftirqd/0/4 [HC0[0]:SC1[1]:HE1:SE0] takes:\n\u003e  (\u0026rcu_ctrlblk.lock){-+..}, at: [\u003cc016d91c\u003e] __rcu_process_callbacks+0x1ac/0x1f0\n\u003e {softirq-on-W} state was registered at:\n\u003e   [\u003cc01528e4\u003e] __lock_acquire+0x3f4/0x5b0\n\u003e   [\u003cc0152b29\u003e] lock_acquire+0x89/0xc0\n\u003e   [\u003cc076142b\u003e] _spin_lock+0x3b/0x70\n\u003e   [\u003cc016d649\u003e] rcu_init_percpu_data+0x29/0x80\n\u003e   [\u003cc075e43f\u003e] rcu_cpu_notify+0xaf/0xd0\n\u003e   [\u003cc076458d\u003e] notifier_call_chain+0x2d/0x60\n\u003e   [\u003cc0145ede\u003e] __raw_notifier_call_chain+0x1e/0x30\n\u003e   [\u003cc075db29\u003e] _cpu_up+0x79/0x110\n\u003e   [\u003cc075dc0d\u003e] cpu_up+0x4d/0x70\n\u003e   [\u003cc0a769e1\u003e] kernel_init+0xb1/0x200\n\u003e   [\u003cc01048a3\u003e] kernel_thread_helper+0x7/0x10\n\u003e   [\u003cffffffff\u003e] 0xffffffff\n\u003e irq event stamp: 14\n\u003e hardirqs last  enabled at (14): [\u003cc01534db\u003e] trace_hardirqs_on+0xb/0x10\n\u003e hardirqs last disabled at (13): [\u003cc014dbeb\u003e] trace_hardirqs_off+0xb/0x10\n\u003e softirqs last  enabled at (0): [\u003cc012b186\u003e] copy_process+0x276/0x1190\n\u003e softirqs last disabled at (11): [\u003cc0105c0a\u003e] call_on_stack+0x1a/0x30\n\u003e\n\u003e other info that might help us debug this:\n\u003e no locks held by ksoftirqd/0/4.\n\u003e\n\u003e stack backtrace:\n\u003e Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.27-rc3-tip #1\n\u003e  [\u003cc01504dc\u003e] print_usage_bug+0x16c/0x1b0\n\u003e  [\u003cc0152455\u003e] mark_lock+0xa75/0xb10\n\u003e  [\u003cc0108b75\u003e] ? sched_clock+0x15/0x30\n\u003e  [\u003cc015289d\u003e] __lock_acquire+0x3ad/0x5b0\n\u003e  [\u003cc0152b29\u003e] lock_acquire+0x89/0xc0\n\u003e  [\u003cc016d91c\u003e] ? __rcu_process_callbacks+0x1ac/0x1f0\n\u003e  [\u003cc076142b\u003e] _spin_lock+0x3b/0x70\n\u003e  [\u003cc016d91c\u003e] ? __rcu_process_callbacks+0x1ac/0x1f0\n\u003e  [\u003cc016d91c\u003e] __rcu_process_callbacks+0x1ac/0x1f0\n\u003e  [\u003cc016d986\u003e] rcu_process_callbacks+0x26/0x50\n\u003e  [\u003cc0132305\u003e] __do_softirq+0x95/0x120\n\u003e  [\u003cc0132270\u003e] ? __do_softirq+0x0/0x120\n\u003e  [\u003cc0105c0a\u003e] call_on_stack+0x1a/0x30\n\u003e  [\u003cc0132426\u003e] ? ksoftirqd+0x96/0x110\n\u003e  [\u003cc0132390\u003e] ? ksoftirqd+0x0/0x110\n\u003e  [\u003cc01411f7\u003e] ? kthread+0x47/0x80\n\u003e  [\u003cc01411b0\u003e] ? kthread+0x0/0x80\n\u003e  [\u003cc01048a3\u003e] ? kernel_thread_helper+0x7/0x10\n\u003e  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\u003e calling  init_cpufreq_transition_notifier_list+0x0/0x20\n\u003e initcall init_cpufreq_transition_notifier_list+0x0/0x20 returned 0 after 0 msecs\n\u003e calling  net_ns_init+0x0/0x190\n\u003e net_namespace: 676 bytes\n\u003e initcall net_ns_init+0x0/0x190 returned 0 after 0 msecs\n\u003e calling  cpufreq_tsc+0x0/0x20\n\u003e initcall cpufreq_tsc+0x0/0x20 returned 0 after 0 msecs\n\u003e calling  reboot_init+0x0/0x20\n\u003e initcall reboot_init+0x0/0x20 returned 0 after 0 msecs\n\u003e calling  print_banner+0x0/0x10\n\u003e Booting paravirtualized kernel on bare hardware\n\u003e\n\u003e \u003c-----------------------\n\u003e\n\u003e my guess is on:\n\u003e\n\u003e  commit 1f7b94cd3d564901f9e04a8bc5832ae7bfd690a0\n\u003e  Author: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\n\u003e  Date:   Tue Aug 5 09:21:44 2008 -0700\n\u003e\n\u003e     rcu: classic RCU locking and memory-barrier cleanups\n\u003e\n\u003e \tIngo\n\nFixes a problem detected by lockdep in which rcu-\u003elock was acquired\nboth in irq context and in process context, but without disabling from\nprocess context.\n\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5de126630b109ae5e1bc1db6207d0c278b644133",
      "old_mode": 33188,
      "old_path": "kernel/rcuclassic.c",
      "new_id": "fb1f1cc45142ec74ff4ff2e9bc38e962064505be",
      "new_mode": 33188,
      "new_path": "kernel/rcuclassic.c"
    }
  ]
}