)]}'
{
  "commit": "13c22168b7276dffe49dc66675d5a78f6d288e0d",
  "tree": "4062929954f04db9c24be08cba94a0ed6e7fd65f",
  "parents": [
    "87a7defb0d4255d5aea2c5067813b26836127983"
  ],
  "author": {
    "name": "Oleg Nesterov",
    "email": "oleg@tv-sign.ru",
    "time": "Tue Jul 17 04:03:55 2007 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@woody.linux-foundation.org",
    "time": "Tue Jul 17 10:23:03 2007 -0700"
  },
  "message": "destroy_workqueue() can livelock\n\nPointed out by Michal Schmidt \u003cmschmidt@redhat.com\u003e.\n\nThe bug was introduced in 2.6.22 by me.\n\ncleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until\n-\u003eworklist becomes empty.  This is live-lockable, a re-niced caller can get\nCPU after wake_up() and insert a new barrier before the lower-priority\ncwq-\u003ethread has a chance to clear -\u003ecurrent_work.\n\nChange cleanup_workqueue_thread() to do flush_cpu_workqueue(cwq) only once.\n We can rely on the fact that run_workqueue() won\u0027t return until it flushes\nall works.  So it is safe to call kthread_stop() after that, the \"should\nstop\" request won\u0027t be noticed until run_workqueue() returns.\n\nSigned-off-by: Oleg Nesterov \u003coleg@tv-sign.ru\u003e\nCc: Michal Schmidt \u003cmschmidt@redhat.com\u003e\nCc: Srivatsa Vaddagiri \u003cvatsa@in.ibm.com\u003e\nCc: \u003cstable@kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1935302cc645d22dcbe1403085fe623382645190",
      "old_mode": 33188,
      "old_path": "kernel/workqueue.c",
      "new_id": "58e5c152a6bb9c2283937a84ec431eac73fc5b87",
      "new_mode": 33188,
      "new_path": "kernel/workqueue.c"
    }
  ]
}