)]}'
{
  "commit": "eee0f252c6537da2e883f75d22cff1427515eaf3",
  "tree": "87ca6a49dd2d299b6cb4146ff3295bb625519b05",
  "parents": [
    "5dbe0af47f8a8f968bac2991c3ec974c6e3eaabc"
  ],
  "author": {
    "name": "Hugh Dickins",
    "email": "hughd@google.com",
    "time": "Sat May 28 13:20:21 2011 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sat May 28 16:55:32 2011 -0700"
  },
  "message": "mm: fix page_lock_anon_vma leaving mutex locked\n\nOn one machine I\u0027ve been getting hangs, a page fault\u0027s anon_vma_prepare()\nwaiting in anon_vma_lock(), other processes waiting for that page\u0027s lock.\n\nThis is a replay of last year\u0027s f18194275c39 \"mm: fix hang on\nanon_vma-\u003eroot-\u003elock\".\n\nThe new page_lock_anon_vma() places too much faith in its refcount: when\nit has acquired the mutex_trylock(), it\u0027s possible that a racing task in\nanon_vma_alloc() has just reallocated the struct anon_vma, set refcount\nto 1, and is about to reset its anon_vma-\u003eroot.\n\nFix this by saving anon_vma-\u003eroot, and relying on the usual page_mapped()\ncheck instead of a refcount check: if page is still mapped, the anon_vma\nis still ours; if page is not still mapped, we\u0027re no longer interested.\n\nSigned-off-by: Hugh Dickins \u003chughd@google.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ba58ca36fc90c9f5b92db256fdd431c1f94ea4f0",
      "old_mode": 33188,
      "old_path": "mm/rmap.c",
      "new_id": "6bada99cd61c51cf98e36728b0ba646bd1410580",
      "new_mode": 33188,
      "new_path": "mm/rmap.c"
    }
  ]
}