)]}'
{
  "commit": "0e5c0e91bbeed6ba42c11d5e82aa71e85d2e45e4",
  "tree": "c52205b4d2007e96c9ee609f70ca231d529dd720",
  "parents": [
    "1e4abab8b49ceef6e422100bbc6fdb345a4274ed"
  ],
  "author": {
    "name": "Kalesh Singh",
    "email": "kaleshsingh@google.com",
    "time": "Mon Dec 19 21:07:49 2022 -0800"
  },
  "committer": {
    "name": "Kalesh Singh",
    "email": "kaleshsingh@google.com",
    "time": "Tue Jan 10 08:40:35 2023 -0800"
  },
  "message": "ANDROID: Re-enable fast mremap and fix UAF with SPF\n\nSPF attempts page faults without taking the mmap lock, but takes the\nPTL. If there is a concurrent fast mremap (at PMD/PUD level), this\ncan lead to a UAF as fast mremap will only take the PTL locks at the\nPMD/PUD level. SPF cannot take the PTL locks at the larger subtree\ngranularity since this introduces much contention in the page fault\npaths.\n\nTo address the race:\n  1) Only try fast mremaps if there are no users of the VMA. Android\n     is concerned with this optimization in the context of\n     GC stop-the-world pause. So there are no other threads active\n     and this should almost always succeed.\n  2) Speculative faults detect ongoing fast mremaps and fallback\n     to conventional fault handling (taking mmap read lock).\n\nBug: 263177905\nBug: 264693867\nChange-Id: I23917e493ddc8576de19883cac053dfde9982b7f\nSigned-off-by: Kalesh Singh \u003ckaleshsingh@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "29b373b876a95d5a65858ddaf6a5acf886dd5e20",
      "old_mode": 33188,
      "old_path": "mm/mmap.c",
      "new_id": "69c096503774370e21a3e0ae40c8b1095af11920",
      "new_mode": 33188,
      "new_path": "mm/mmap.c"
    },
    {
      "type": "modify",
      "old_id": "6abbaf1eea97325fcccd3f275690b2382c2d9639",
      "old_mode": 33188,
      "old_path": "mm/mremap.c",
      "new_id": "a6484e84570654d8967bb0dc809e75da87c2986f",
      "new_mode": 33188,
      "new_path": "mm/mremap.c"
    }
  ]
}