)]}'
{
  "commit": "0b3dae68ac199fac224fea9a31907b44f0d257b3",
  "tree": "909b0b1d33123c9e8cbd0117e5f42df12e3becde",
  "parents": [
    "4468a00fd9a274fe1b30c886370d662e4a439efb"
  ],
  "author": {
    "name": "Lai Jiangshan",
    "email": "laijs@cn.fujitsu.com",
    "time": "Wed Feb 06 18:04:53 2013 -0800"
  },
  "committer": {
    "name": "Tejun Heo",
    "email": "tj@kernel.org",
    "time": "Wed Feb 06 18:04:53 2013 -0800"
  },
  "message": "workqueue: simplify is-work-item-queued-here test\n\nCurrently, determining whether a work item is queued on a locked pool\ninvolves somewhat convoluted memory barrier dancing.  It goes like the\nfollowing.\n\n* When a work item is queued on a pool, work-\u003edata is updated before\n  work-\u003eentry is linked to the pending list with a wmb() inbetween.\n\n* When trying to determine whether a work item is currently queued on\n  a pool pointed to by work-\u003edata, it locks the pool and looks at\n  work-\u003eentry.  If work-\u003eentry is linked, we then do rmb() and then\n  check whether work-\u003edata points to the current pool.\n\nThis works because, work-\u003edata can only point to a pool if it\ncurrently is or were on the pool and,\n\n* If it currently is on the pool, the tests would obviously succeed.\n\n* It it left the pool, its work-\u003eentry was cleared under pool-\u003elock,\n  so if we\u0027re seeing non-empty work-\u003eentry, it has to be from the work\n  item being linked on another pool.  Because work-\u003edata is updated\n  before work-\u003eentry is linked with wmb() inbetween, work-\u003edata update\n  from another pool is guaranteed to be visible if we do rmb() after\n  seeing non-empty work-\u003eentry.  So, we either see empty work-\u003eentry\n  or we see updated work-\u003edata pointin to another pool.\n\nWhile this works, it\u0027s convoluted, to put it mildly.  With recent\nupdates, it\u0027s now guaranteed that work-\u003edata points to cwq only while\nthe work item is queued and that updating work-\u003edata to point to cwq\nor back to pool is done under pool-\u003elock, so we can simply test\nwhether work-\u003edata points to cwq which is associated with the\ncurrently locked pool instead of the convoluted memory barrier\ndancing.\n\nThis patch replaces the memory barrier based \"are you still here,\nreally?\" test with much simpler \"does work-\u003edata points to me?\" test -\nif work-\u003edata points to a cwq which is associated with the currently\nlocked pool, the work item is guaranteed to be queued on the pool as\nwork-\u003edata can start and stop pointing to such cwq only under\npool-\u003elock and the start and stop coincide with queue and dequeue.\n\ntj: Rewrote the comments and description.\n\nSigned-off-by: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1a442c301ddb93431e14d3d043633377d5059867",
      "old_mode": 33188,
      "old_path": "kernel/workqueue.c",
      "new_id": "251f00914295036ae1f2e528a67e3d9851a433e7",
      "new_mode": 33188,
      "new_path": "kernel/workqueue.c"
    }
  ]
}