)]}'
{
  "commit": "26861faf896a4cfdc4243281e5c305755f4bad52",
  "tree": "c93082f55b437b3b949b4bf0207d9be1a6fcd1fd",
  "parents": [
    "f38bd1020f797694b6b5e06f5f06c87688fc84c0"
  ],
  "author": {
    "name": "Paul E. McKenney",
    "email": "paul.mckenney@linaro.org",
    "time": "Wed Jan 11 14:40:20 2012 -0800"
  },
  "committer": {
    "name": "Paul E. McKenney",
    "email": "paulmck@linux.vnet.ibm.com",
    "time": "Tue Feb 21 09:03:39 2012 -0800"
  },
  "message": "rcu: Protect __rcu_read_unlock() against scheduler-using irq handlers\n\nThis commit ports commit #10f39bb1b2 (rcu: protect __rcu_read_unlock()\nagainst scheduler-using irq handlers) from TREE_PREEMPT_RCU to\nTINY_PREEMPT_RCU.  The following is a corresponding port of that\ncommit message.\n\nThe addition of RCU read-side critical sections within runqueue and\npriority-inheritance critical sections introduced some deadlocks,\nfor example, involving interrupts from __rcu_read_unlock() where the\ninterrupt handlers call wake_up().  This situation can cause the\ninstance of __rcu_read_unlock() invoked from interrupt to do some\nof the processing that would otherwise have been carried out by the\ntask-level instance of __rcu_read_unlock().  When the interrupt-level\ninstance of __rcu_read_unlock() is called with a scheduler lock held from\ninterrupt-entry/exit situations where in_irq() returns false, deadlock can\nresult.  Of course, in a UP kernel, there are not really any deadlocks,\nbut the upper-level critical section can still be be fatally confused\nby the lower-level critical section changing things out from under it.\n\nThis commit resolves these deadlocks by using negative values of the\nper-task -\u003ercu_read_lock_nesting counter to indicate that an instance of\n__rcu_read_unlock() is in flight, which in turn prevents instances from\ninterrupt handlers from doing any special processing.  Note that nested\nrcu_read_lock()/rcu_read_unlock() pairs are still permitted, but they will\nnever see -\u003ercu_read_lock_nesting go to zero, and will therefore never\ninvoke rcu_read_unlock_special(), thus preventing them from seeing the\nRCU_READ_UNLOCK_BLOCKED bit should it be set in -\u003ercu_read_unlock_special.\nThis patch also adds a check for -\u003ercu_read_unlock_special being negative\nin rcu_check_callbacks(), thus preventing the RCU_READ_UNLOCK_NEED_QS\nbit from being set should a scheduling-clock interrupt occur while\n__rcu_read_unlock() is exiting from an outermost RCU read-side critical\nsection.\n\nOf course, __rcu_read_unlock() can be preempted during the time that\n-\u003ercu_read_lock_nesting is negative.  This could result in the setting\nof the RCU_READ_UNLOCK_BLOCKED bit after __rcu_read_unlock() checks it,\nand would also result it this task being queued on the corresponding\nrcu_node structure\u0027s blkd_tasks list.  Therefore, some later RCU read-side\ncritical section would enter rcu_read_unlock_special() to clean up --\nwhich could result in deadlock (OK, OK, fatal confusion) if that RCU\nread-side critical section happened to be in the scheduler where the\nrunqueue or priority-inheritance locks were held.\n\nTo prevent the possibility of fatal confusion that might result from\npreemption during the time that -\u003ercu_read_lock_nesting is negative,\nthis commit also makes rcu_preempt_note_context_switch() check for\nnegative -\u003ercu_read_lock_nesting, thus refraining from queuing the task\n(and from setting RCU_READ_UNLOCK_BLOCKED) if we are already exiting\nfrom the outermost RCU read-side critical section (in other words,\nwe really are no longer actually in that RCU read-side critical\nsection).  In addition, rcu_preempt_note_context_switch() invokes\nrcu_read_unlock_special() to carry out the cleanup in this case, which\nclears out the -\u003ercu_read_unlock_special bits and dequeues the task\n(if necessary), in turn avoiding needless delay of the current RCU grace\nperiod and needless RCU priority boosting.\n\nIt is still illegal to call rcu_read_unlock() while holding a scheduler\nlock if the prior RCU read-side critical section has ever had both\npreemption and irqs enabled.  However, the common use case is legal,\nnamely where then entire RCU read-side critical section executes with\nirqs disabled, for example, when the scheduler lock is held across the\nentire lifetime of the RCU read-side critical section.\n\nSigned-off-by: Paul E. McKenney \u003cpaul.mckenney@linaro.org\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "4b905404a5bdb70966f887e596d0b567a40305e1",
      "old_mode": 33188,
      "old_path": "kernel/rcutiny_plugin.h",
      "new_id": "432ed2bc05ad79d95c0b0666ccba116752222bfc",
      "new_mode": 33188,
      "new_path": "kernel/rcutiny_plugin.h"
    }
  ]
}