)]}'
{
  "commit": "d84e0f10d38393f617227f0c831a99c69294651f",
  "tree": "5d0836f024f1f13ac6f1b2b2d3004244cb0fa649",
  "parents": [
    "91c00924846a0034020451c280c76baa4299f9dc"
  ],
  "author": {
    "name": "Dan Williams",
    "email": "dan.j.williams@intel.com",
    "time": "Tue Jan 02 13:52:30 2007 -0700"
  },
  "committer": {
    "name": "Dan Williams",
    "email": "dan.j.williams@intel.com",
    "time": "Fri Jul 13 08:06:16 2007 -0700"
  },
  "message": "md: common infrastructure for running operations with raid5_run_ops\n\nAll the handle_stripe operations that are to be transitioned to use\nraid5_run_ops need a method to coherently gather work under the stripe-lock\nand hand that work off to raid5_run_ops.  The \u0027get_stripe_work\u0027 routine\nruns under the lock to read all the bits in sh-\u003eops.pending that do not\nhave the corresponding bit set in sh-\u003eops.ack.  This modified \u0027pending\u0027\nbitmap is then passed to raid5_run_ops for processing.\n\nThe transition from \u0027ack\u0027 to \u0027completion\u0027 does not need similar protection\nas the existing release_stripe infrastructure will guarantee that\nhandle_stripe will run again after a completion bit is set, and\nhandle_stripe can tolerate a sh-\u003eops.completed bit being set while the lock\nis held.\n\nA call to async_tx_issue_pending_all() is added to raid5d to kick the\noffload engines once all pending stripe operations work has been submitted.\nThis enables batching of the submission and completion of operations.\n\nSigned-off-by: Dan Williams \u003cdan.j.williams@intel.com\u003e\nAcked-By: NeilBrown \u003cneilb@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0b7002479655008e028cb1f80ab354b424460125",
      "old_mode": 33188,
      "old_path": "drivers/md/raid5.c",
      "new_id": "d89a25e7c17bb0d50b0bc78bb290877ddb31ea8a",
      "new_mode": 33188,
      "new_path": "drivers/md/raid5.c"
    }
  ]
}