)]}'
{
  "commit": "3935baa9bcda3ccaee4f7849f5157d316e34412e",
  "tree": "45f6d064693a91171c57159acac43822cae6e129",
  "parents": [
    "79ac6ba40eb8d70f0d204e98ae9b63280ad1018c"
  ],
  "author": {
    "name": "David Gibson",
    "email": "david@gibson.dropbear.id.au",
    "time": "Wed Mar 22 00:08:53 2006 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@g5.osdl.org",
    "time": "Wed Mar 22 07:54:03 2006 -0800"
  },
  "message": "[PATCH] hugepage: serialize hugepage allocation and instantiation\n\nCurrently, no lock or mutex is held between allocating a hugepage and\ninserting it into the pagetables / page cache.  When we do go to insert the\npage into pagetables or page cache, we recheck and may free the newly\nallocated hugepage.  However, since the number of hugepages in the system\nis strictly limited, and it\u0027s usualy to want to use all of them, this can\nstill lead to spurious allocation failures.\n\nFor example, suppose two processes are both mapping (MAP_SHARED) the same\nhugepage file, large enough to consume the entire available hugepage pool.\nIf they race instantiating the last page in the mapping, they will both\nattempt to allocate the last available hugepage.  One will fail, of course,\nreturning OOM from the fault and thus causing the process to be killed,\ndespite the fact that the entire mapping can, in fact, be instantiated.\n\nThe patch fixes this race by the simple method of adding a (sleeping) mutex\nto serialize the hugepage fault path between allocation and insertion into\npagetables and/or page cache.  It would be possible to avoid the\nserialization by catching the allocation failures, waiting on some\ncondition, then rechecking to see if someone else has instantiated the page\nfor us.  Given the likely frequency of hugepage instantiations, it seems\nvery doubtful it\u0027s worth the extra complexity.\n\nThis patch causes no regression on the libhugetlbfs testsuite, and one\ntest, which can trigger this race now passes where it previously failed.\n\nActually, the test still sometimes fails, though less often and only as a\nshmat() failure, rather processes getting OOM killed by the VM.  The dodgy\nheuristic tests in fs/hugetlbfs/inode.c for whether there\u0027s enough hugepage\nspace aren\u0027t protected by the new mutex, and would be ugly to do so, so\nthere\u0027s still a race there.  Another patch to replace those tests with\nsomething saner for this reason as well as others coming...\n\nSigned-off-by: David Gibson \u003cdwg@au1.ibm.com\u003e\nCc: William Lee Irwin III \u003cwli@holomorphy.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": "41b1038f76dafa88d6f14c43319522656680e4e7",
      "old_mode": 33188,
      "old_path": "mm/hugetlb.c",
      "new_id": "d5987a87bbe536306a076796cc486a9078df3fe6",
      "new_mode": 33188,
      "new_path": "mm/hugetlb.c"
    }
  ]
}