)]}'
{
  "commit": "4247bdc60048018b98f71228b45cfbc5f5270c86",
  "tree": "6f6abbd10685af84c97e661da6771726a12209ac",
  "parents": [
    "fb1c8f93d869b34cacb8b8932e2b83d96a19d720"
  ],
  "author": {
    "name": "Paul Jackson",
    "email": "pj@sgi.com",
    "time": "Sat Sep 10 00:26:06 2005 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@g5.osdl.org",
    "time": "Sat Sep 10 10:06:21 2005 -0700"
  },
  "message": "[PATCH] cpuset semaphore depth check deadlock fix\n\nThe cpusets-formalize-intermediate-gfp_kernel-containment patch\nhas a deadlock problem.\n\nThis patch was part of a set of four patches to make more\nextensive use of the cpuset \u0027mem_exclusive\u0027 attribute to\nmanage kernel GFP_KERNEL memory allocations and to constrain\nthe out-of-memory (oom) killer.\n\nA task that is changing cpusets in particular ways on a system\nwhen it is very short of free memory could double trip over\nthe global cpuset_sem semaphore (get the lock and then deadlock\ntrying to get it again).\n\nThe second attempt to get cpuset_sem would be in the routine\ncpuset_zone_allowed().  This was discovered by code inspection.\nI can not reproduce the problem except with an artifically\nhacked kernel and a specialized stress test.\n\nIn real life you cannot hit this unless you are manipulating\ncpusets, and are very unlikely to hit it unless you are rapidly\nmodifying cpusets on a memory tight system.  Even then it would\nbe a rare occurence.\n\nIf you did hit it, the task double tripping over cpuset_sem\nwould deadlock in the kernel, and any other task also trying\nto manipulate cpusets would deadlock there too, on cpuset_sem.\nYour batch manager would be wedged solid (if it was cpuset\nsavvy), but classic Unix shells and utilities would work well\nenough to reboot the system.\n\nThe unusual condition that led to this bug is that unlike most\nsemaphores, cpuset_sem _can_ be acquired while in the page\nallocation code, when __alloc_pages() calls cpuset_zone_allowed.\nSo it easy to mistakenly perform the following sequence:\n  1) task makes system call to alter a cpuset\n  2) take cpuset_sem\n  3) try to allocate memory\n  4) memory allocator, via cpuset_zone_allowed, trys to take cpuset_sem\n  5) deadlock\n\nThe reason that this is not a serious bug for most users\nis that almost all calls to allocate memory don\u0027t require\ntaking cpuset_sem.  Only some code paths off the beaten\ntrack require taking cpuset_sem -- which is good.  Taking\na global semaphore on the main code path for allocating\nmemory would not scale well.\n\nThis patch fixes this deadlock by wrapping the up() and down()\ncalls on cpuset_sem in kernel/cpuset.c with code that tracks\nthe nesting depth of the current task on that semaphore, and\nonly does the real down() if the task doesn\u0027t hold the lock\nalready, and only does the real up() if the nesting depth\n(number of unmatched downs) is exactly one.\n\nThe previous required use of refresh_mems(), anytime that\nthe cpuset_sem semaphore was acquired and the code executed\nwhile holding that semaphore might try to allocate memory, is\nno longer required.  Two refresh_mems() calls were removed\nthanks to this.  This is a good change, as failing to get\nall the necessary refresh_mems() calls placed was a primary\nsource of bugs in this cpuset code.  The only remaining call\nto refresh_mems() is made while doing a memory allocation,\nif certain task memory placement data needs to be updated\nfrom its cpuset, due to the cpuset having been changed behind\nthe tasks back.\n\nSigned-off-by: Paul Jackson \u003cpj@sgi.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c551e6a1447e57949e84435fe3fb846799d30f8b",
      "old_mode": 33188,
      "old_path": "include/linux/sched.h",
      "new_id": "8a1fcfe80fc722ff11c33d044ed195b9e05bc877",
      "new_mode": 33188,
      "new_path": "include/linux/sched.h"
    },
    {
      "type": "modify",
      "old_id": "712d02029971ed456a4025d23f0cd4d187d2f6ff",
      "old_mode": 33188,
      "old_path": "kernel/cpuset.c",
      "new_id": "407b5f0a8c8eeed2aea648b08748771dd284b3d7",
      "new_mode": 33188,
      "new_path": "kernel/cpuset.c"
    }
  ]
}