)]}'
{
  "commit": "83f5b01ffbbaea6f97c9a79d21e240dbfb69f2f1",
  "tree": "e278471f3b9851028ef60e283ce8c73772531d82",
  "parents": [
    "b00bc0b237055b4c45816325ee14f0bd83e6f590"
  ],
  "author": {
    "name": "Paul E. McKenney",
    "email": "paulmck@linux.vnet.ibm.com",
    "time": "Wed Oct 28 08:14:49 2009 -0700"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Mon Nov 02 16:06:21 2009 +0100"
  },
  "message": "rcu: Fix long-grace-period race between forcing and initialization\n\nVery long RCU read-side critical sections (50 milliseconds or\nso) can cause a race between force_quiescent_state() and\nrcu_start_gp() as follows on kernel builds with multi-level\nrcu_node hierarchies:\n\n1.\tCPU 0 calls force_quiescent_state(), sees that there is a\n\tgrace period in progress, and acquires -\u003efsqlock.\n\n2.\tCPU 1 detects the end of the grace period, and so\n\tcpu_quiet_msk_finish() sets rsp-\u003ecompleted to rsp-\u003egpnum.\n\tThis operation is carried out under the root rnp-\u003elock,\n\tbut CPU 0 has not yet acquired that lock.  Note that\n\trsp-\u003esignaled is still RCU_SAVE_DYNTICK from the last\n\tgrace period.\n\n3.\tCPU 1 calls rcu_start_gp(), but no one wants a new grace\n\tperiod, so it drops the root rnp-\u003elock and returns.\n\n4.\tCPU 0 acquires the root rnp-\u003elock and picks up rsp-\u003ecompleted\n\tand rsp-\u003esignaled, then drops rnp-\u003elock.  It then enters the\n\tRCU_SAVE_DYNTICK leg of the switch statement.\n\n5.\tCPU 2 invokes call_rcu(), and now needs a new grace period.\n\tIt calls rcu_start_gp(), which acquires the root rnp-\u003elock, sets\n\trsp-\u003esignaled to RCU_GP_INIT (too bad that CPU 0 is already in\n\tthe RCU_SAVE_DYNTICK leg of the switch statement!)  and starts\n\tinitializing the rcu_node hierarchy.  If there are multiple\n\tlevels to the hierarchy, it will drop the root rnp-\u003elock and\n\tinitialize the lower levels of the hierarchy.\n\n6.\tCPU 0 notes that rsp-\u003ecompleted has not changed, which permits\n        both CPU 2 and CPU 0 to try updating it concurrently.  If CPU 0\u0027s\n\tupdate prevails, later calls to force_quiescent_state() can\n\tcount old quiescent states against the new grace period, which\n\tcan in turn result in premature ending of grace periods.\n\n\tNot good.\n\nThis patch adds an RCU_GP_IDLE state for rsp-\u003esignaled that is\nset initially at boot time and any time a grace period ends.\nThis prevents CPU 0 from getting into the workings of\nforce_quiescent_state() in step 4.  Additional locking and\nchecks prevent the concurrent update of rsp-\u003esignaled in step 6.\n\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nCc: laijs@cn.fujitsu.com\nCc: dipankar@in.ibm.com\nCc: mathieu.desnoyers@polymtl.ca\nCc: josh@joshtriplett.org\nCc: dvhltc@us.ibm.com\nCc: niv@us.ibm.com\nCc: peterz@infradead.org\nCc: rostedt@goodmis.org\nCc: Valdis.Kletnieks@vt.edu\nCc: dhowells@redhat.com\nLKML-Reference: \u003c1256742889199-git-send-email-\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0536125b0497ab0d5f66bac3dc81ecec26fbd0ea",
      "old_mode": 33188,
      "old_path": "kernel/rcutree.c",
      "new_id": "f3077c0ab1813379ef4f225168280387fa89a917",
      "new_mode": 33188,
      "new_path": "kernel/rcutree.c"
    },
    {
      "type": "modify",
      "old_id": "1823c6e20609405e4bb0ecbc235dc7709546b7a3",
      "old_mode": 33188,
      "old_path": "kernel/rcutree.h",
      "new_id": "1899023b0962adec0968bb32a7bdfd5dbebc577e",
      "new_mode": 33188,
      "new_path": "kernel/rcutree.h"
    }
  ]
}