)]}'
{
  "commit": "be068f29034fb00530a053d18b8cf140c32b12b3",
  "tree": "e963d43b2f961109a42637250c77eedbd3187e3f",
  "parents": [
    "c9c9e6a49f8998e9334507378c08cc16cb3ec0e5"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Sep 24 08:41:32 2020 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Sep 24 08:41:32 2020 -0700"
  },
  "message": "mm: fix misplaced unlock_page in do_wp_page()\n\nCommit 09854ba94c6a (\"mm: do_wp_page() simplification\") reorganized all\nthe code around the page re-use vs copy, but in the process also moved\nthe final unlock_page() around to after the wp_page_reuse() call.\n\nThat normally doesn\u0027t matter - but it means that the unlock_page() is\nnow done after releasing the page table lock.  Again, not a big deal,\nyou\u0027d think.\n\nBut it turns out that it\u0027s very wrong indeed, because once we\u0027ve\nreleased the page table lock, we\u0027ve basically lost our only reference to\nthe page - the page tables - and it could now be free\u0027d at any time.  We\ndo hold the mmap_sem, so no actual unmap() can happen, but madvise can\ncome in and a MADV_DONTNEED will zap the page range - and free the page.\n\nSo now the page may be free\u0027d just as we\u0027re unlocking it, which in turn\nwill usually trigger a \"Bad page state\" error in the freeing path.  To\nmake matters more confusing, by the time the debug code prints out the\npage state, the unlock has typically completed and everything looks fine\nagain.\n\nThis all doesn\u0027t happen in any normal situations, but it does trigger\nwith the dirtyc0w_child LTP test.  And it seems to trigger much more\neasily (but not expclusively) on s390 than elsewhere, probably because\ns390 doesn\u0027t do the \"batch pages up for freeing after the TLB flush\"\nthat gives the unlock_page() more time to complete and makes the race\nharder to hit.\n\nFixes: 09854ba94c6a (\"mm: do_wp_page() simplification\")\nLink: https://lore.kernel.org/lkml/a46e9bbef2ed4e17778f5615e818526ef848d791.camel@redhat.com/\nLink: https://lore.kernel.org/linux-mm/c41149a8-211e-390b-af1d-d5eee690fecb@linux.alibaba.com/\nReported-by: Qian Cai \u003ccai@redhat.com\u003e\nReported-by: Alex Shi \u003calex.shi@linux.alibaba.com\u003e\nBisected-and-analyzed-by: Gerald Schaefer \u003cgerald.schaefer@linux.ibm.com\u003e\nTested-by: Gerald Schaefer \u003cgerald.schaefer@linux.ibm.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e315b1f1ef084103196e712b3ba9188d2bff1aa2",
      "old_mode": 33188,
      "old_path": "mm/memory.c",
      "new_id": "f3eb5597590232bab80dac0e4b31c5a1c92c8eda",
      "new_mode": 33188,
      "new_path": "mm/memory.c"
    }
  ]
}