)]}'
{
  "commit": "ea90002b0fa7bdee86ec22eba1d951f30bf043a6",
  "tree": "7620aa0da5b7314769b177dd0934bb87fe7c993b",
  "parents": [
    "646d87b481dab4ba8301716600dfd276605b0ab0"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Apr 12 12:44:29 2010 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Apr 12 17:54:13 2010 -0700"
  },
  "message": "anonvma: when setting up page-\u003emapping, we need to pick the _oldest_ anonvma\n\nOtherwise we might be mapping in a page in a new mapping, but that page\n(through the swapcache) would later be mapped into an old mapping too.\nThe page-\u003emapping must be the case that works for everybody, not just\nthe mapping that happened to page it in first.\n\nHere\u0027s the scenario:\n\n - page gets allocated/mapped by process A. Let\u0027s call the anon_vma we\n   associate the page with \u0027A\u0027 to keep it easy to track.\n\n - Process A forks, creating process B. The anon_vma in B is \u0027B\u0027, and has\n   a chain that looks like \u0027B\u0027 -\u003e \u0027A\u0027. Everything is fine.\n\n - Swapping happens. The page (with mapping pointing to \u0027A\u0027) gets swapped\n   out (perhaps not to disk - it\u0027s enough to assume that it\u0027s just not\n   mapped any more, and lives entirely in the swap-cache)\n\n - Process B pages it in, which goes like this:\n\n        do_swap_page -\u003e\n          page \u003d lookup_swap_cache(entry);\n         ...\n          set_pte_at(mm, address, page_table, pte);\n          page_add_anon_rmap(page, vma, address);\n\n   And think about what happens here!\n\n   In particular, what happens is that this will now be the \"first\"\n   mapping of that page, so page_add_anon_rmap() used to do\n\n        if (first)\n                __page_set_anon_rmap(page, vma, address);\n\n   and notice what anon_vma it will use? It will use the anon_vma for\n   process B!\n\n   What happens then? Trivial: process \u0027A\u0027 also pages it in (nothing\n   happens, it\u0027s not the first mapping), and then process \u0027B\u0027 execve\u0027s\n   or exits or unmaps, making anon_vma B go away.\n\n   End result: process A has a page that points to anon_vma B, but\n   anon_vma B does not exist any more.  This can go on forever.  Forget\n   about RCU grace periods, forget about locking, forget anything like\n   that.  The bug is simply that page-\u003emapping points to an anon_vma\n   that was correct at one point, but was _not_ the one that was shared\n   by all users of that possible mapping.\n\nChanging it to always use the deepest anon_vma in the anonvma chain gets\nus to the safest model.\n\nThis can be improved in certain cases: if we know the page is private to\njust this particular mapping (for example, it\u0027s a new page, or it is the\nonly swapcache entry), we could pick the top (most specific) anon_vma.\n\nBut that\u0027s a future optimization. Make it _work_ reliably first.\n\nReviewed-by: Rik van Riel \u003criel@redhat.com\u003e\nAcked-by: Johannes Weiner \u003channes@cmpxchg.org\u003e\nTested-by: Borislav Petkov \u003cbp@alien8.de\u003e [ \"What do you know, I think you fixed it!\" ]\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ee97d38ed7d9ffcb45686e3395cd87d3b26b872b",
      "old_mode": 33188,
      "old_path": "mm/rmap.c",
      "new_id": "4bad3267537a8c7826d313afa661a03f51b2df26",
      "new_mode": 33188,
      "new_path": "mm/rmap.c"
    }
  ]
}