)]}'
{
  "commit": "ffef67b93aa352b34e6aeba3d52c19a63885409a",
  "tree": "559ae5aae50fa71a4136ba3836fce98bd3df43eb",
  "parents": [
    "6557004a8b59c7701e695f02be03c7e20ed1cc15"
  ],
  "author": {
    "name": "David Hildenbrand (Arm)",
    "email": "david@kernel.org",
    "time": "Mon Mar 23 21:20:18 2026 +0100"
  },
  "committer": {
    "name": "Andrew Morton",
    "email": "akpm@linux-foundation.org",
    "time": "Fri Mar 27 20:48:38 2026 -0700"
  },
  "message": "mm/memory: fix PMD/PUD checks in follow_pfnmap_start()\n\nfollow_pfnmap_start() suffers from two problems:\n\n(1) We are not re-fetching the pmd/pud after taking the PTL\n\nTherefore, we are not properly stabilizing what the lock actually\nprotects.  If there is concurrent zapping, we would indicate to the\ncaller that we found an entry, however, that entry might already have\nbeen invalidated, or contain a different PFN after taking the lock.\n\nProperly use pmdp_get() / pudp_get() after taking the lock.\n\n(2) pmd_leaf() / pud_leaf() are not well defined on non-present entries\n\npmd_leaf()/pud_leaf() could wrongly trigger on non-present entries.\n\nThere is no real guarantee that pmd_leaf()/pud_leaf() returns something\nreasonable on non-present entries.  Most architectures indeed either\nperform a present check or make it work by smart use of flags.\n\nHowever, for example loongarch checks the _PAGE_HUGE flag in pmd_leaf(),\nand always sets the _PAGE_HUGE flag in __swp_entry_to_pmd().  Whereby\npmd_trans_huge() explicitly checks pmd_present(), pmd_leaf() does not do\nthat.\n\nLet\u0027s check pmd_present()/pud_present() before assuming \"the is a present\nPMD leaf\" when spotting pmd_leaf()/pud_leaf(), like other page table\nhandling code that traverses user page tables does.\n\nGiven that non-present PMD entries are likely rare in VM_IO|VM_PFNMAP, (1)\nis likely more relevant than (2).  It is questionable how often (1) would\nactually trigger, but let\u0027s CC stable to be sure.\n\nThis was found by code inspection.\n\nLink: https://lkml.kernel.org/r/20260323-follow_pfnmap_fix-v1-1-5b0ec10872b3@kernel.org\nFixes: 6da8e9634bb7 (\"mm: new follow_pfnmap API\")\nSigned-off-by: David Hildenbrand (Arm) \u003cdavid@kernel.org\u003e\nAcked-by: Mike Rapoport (Microsoft) \u003crppt@kernel.org\u003e\nReviewed-by: Lorenzo Stoakes (Oracle) \u003cljs@kernel.org\u003e\nCc: Liam Howlett \u003cliam.howlett@oracle.com\u003e\nCc: Michal Hocko \u003cmhocko@suse.com\u003e\nCc: Peter Xu \u003cpeterx@redhat.com\u003e\nCc: Suren Baghdasaryan \u003csurenb@google.com\u003e\nCc: Vlastimil Babka \u003cvbabka@kernel.org\u003e\nCc: \u003cstable@vger.kernel.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2f815a34d924c58ca7a549226169565afc674146",
      "old_mode": 33188,
      "old_path": "mm/memory.c",
      "new_id": "c65e82c86fed76ec0193a93d54f15a19b3423615",
      "new_mode": 33188,
      "new_path": "mm/memory.c"
    }
  ]
}