From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C16C73C871E; Sun, 27 Sep 2026 21:46:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790545588; cv=none; b=BWASjJs7XmMNfoN4H4sq6qDqIR+36W6dApEmq0OUYnH+U8h/j9VtmPoET2Mk59miWGbKAsEBWjDePFzmGOqZT12bDzw4zU0/8hmvaB2mANeVvHYp/wJLKtYhAOOVWX6+Q32e2eDZ6Wh8fGxuM9rSJogKC6v3iGpefzPPrPDEl+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790545588; c=relaxed/simple; bh=MXGjxUTiPDAlm2Ypz5hDM2lNRUXH5UtltHTW/QoyvYg=; h=Date:To:From:Subject:Message-Id; b=Org5kNrVGM6IV9DZKIA60QX8Ntq5JlZV6t0LFpucZ3oNM0IRJoyGSBkCO11lmNg2CD4WmxTN5w9EAWkWivNc45kr9ET7L5p+w4iskWBDrLqWYLh117HGu/pjrId+s9OK7RTAUeMAV8xSD2YZF7iJ4dNA5sYLvITPO+5UjjOu23M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=lRN3J6Nv; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="lRN3J6Nv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F0F41F00893; Sun, 27 Sep 2026 21:46:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1790545586; bh=u8to28aaLdDVCWWnHiUFIo9kQ+77cShm37qUBXSoH/0=; h=Date:To:From:Subject; b=lRN3J6Nvd7tp7cx9OcNy+TnJpkuXLs3FroOyW39NheBrn4MeTz2g615zRraqdLcRs MQxHcJd1kKXOOkpU+frlx6cC3RdKD56ah2ZvvChfvMnVT7woLPXLx9wzs35nxcwaop t6tlPlUg4XvA9G9BUbg6tTtlbOizJdorA0TtEd9I= Date: Sun, 27 Sep 2026 14:46:25 -0700 To: mm-commits@vger.kernel.org,ziy@nvidia.com,ying.huang@linux.alibaba.com,vbabka@kernel.org,stable@vger.kernel.org,sashiko-bot@kernel.org,rakie.kim@sk.com,peterx@redhat.com,ljs@kernel.org,liam@infradead.org,joshua.hahnjy@gmail.com,jgg@ziepe.ca,jannh@google.com,david@kernel.org,gourry@gourry.net,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-madvise-use-vm_normal_folio_pmd-in-cold-pageout-pmd-range.patch added to mm-unstable branch Message-Id: <20260927214626.5F0F41F00893@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/madvise: use vm_normal_folio_pmd() in cold/pageout PMD range has been added to the -mm mm-unstable branch. Its filename is mm-madvise-use-vm_normal_folio_pmd-in-cold-pageout-pmd-range.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-madvise-use-vm_normal_folio_pmd-in-cold-pageout-pmd-range.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Gregory Price Subject: mm/madvise: use vm_normal_folio_pmd() in cold/pageout PMD range Date: Sat, 26 Sep 2026 06:51:10 -0400 mmap a VM_MIXEDMAP region whose ->huge_fault installs a PMD through vmf_insert_pfn_pmd() - mshv_vtl_low does this, and needs CAP_SYS_ADMIN to open - then: madvise(p, PMD_SIZE, MADV_PAGEOUT); With a stand-in module for the driver: BUG: unable to handle page fault for address: fffff587c0000008 RIP: 0010:madvise_cold_or_pageout_pte_range+0x410/0x9b0 walk_pgd_range+0x52b/0xaf0 __walk_page_range+0x6a/0x1d0 walk_page_range_vma_unsafe+0x8e/0x120 madvise_pageout+0xb2/0x180 madvise_vma_behavior+0x46b/0xa90 do_madvise+0x108/0x190 __x64_sys_madvise+0x26/0x30 Nothing validates the pfn on the way in: can_madv_lru_vma() rejects VM_PFNMAP, but not VM_MIXEDMAP can_fault() *pfn = vmf->pgoff & ~(mask >> PAGE_SHIFT); vmf_insert_pfn_pmd() no pfn_valid() check pmd_folio() pfn_to_page() -> unpopulated vmemmap Even with a valid pfn the path is wrong. The mapping carries no rmap, so folio_maybe_mapped_shared() sees mapcount 0, and the walker goes on to folio_deactivate(), or folio_isolate_lru() plus reclaim_pages(), against a folio this mapping does not own. Use vm_normal_folio_pmd() and skip on NULL, as the PTE half of this same walker already does with vm_normal_folio(). This also filters the huge zero PMD, so its separate check is no longer needed. Link: https://lore.kernel.org/20260926105110.2156652-3-gourry@gourry.net Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260817220810.1175596-1-gourry%40gourry.net Reviewed-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Assisted-by: LLM Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Joshua Hahn Cc: Rakie Kim Cc: Ying Huang Cc: Peter Xu Cc: Jason Gunthorpe Cc: # v6.19+ --- mm/madvise.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/mm/madvise.c~mm-madvise-use-vm_normal_folio_pmd-in-cold-pageout-pmd-range +++ a/mm/madvise.c @@ -395,16 +395,15 @@ static int madvise_cold_or_pageout_pte_r return 0; orig_pmd = *pmd; - if (is_huge_zero_pmd(orig_pmd)) - goto huge_unlock; - if (unlikely(!pmd_present(orig_pmd))) { VM_WARN_ON_ONCE(!pmd_is_migration_entry(orig_pmd) && !pmd_is_device_private_entry(orig_pmd)); goto huge_unlock; } - folio = pmd_folio(orig_pmd); + folio = vm_normal_folio_pmd(vma, addr, orig_pmd); + if (!folio) + goto huge_unlock; if (folio_is_zone_device(folio)) goto huge_unlock; _ Patches currently in -mm which might be from gourry@gourry.net are mm-mempolicy-take-a-cpuset-cookie-for-the-interleave-node-count.patch mm-mempolicy-use-srcu-for-the-weighted-interleave-state.patch mm-mempolicy-stop-copying-the-nodemask-in-the-interleave-paths.patch mm-huge_memory-skip-zone-device-folios-in-madvise_free_huge_pmd.patch mm-madvise-skip-zone-device-folios-in-cold-pageout-pmd-range.patch mm-mempolicy-skip-zone-device-folios-when-queueing-folios.patch mm-memory_hotplug-factor-out-node_is_memoryless.patch mm-mempolicy-use-vm_normal_folio_pmd-in-queue_folios_pmd.patch mm-madvise-use-vm_normal_folio_pmd-in-cold-pageout-pmd-range.patch mm-refactor-find_next_best_node-to-find_next_best_node_in.patch mm-page_alloc-refactor-build_node_zonelist-out-of-build_zonelists.patch proc-task_mmu-handle-special-pmds-in-clear_refs-and-pagemap.patch mm-madvise-reclaim-isolated-folios-if-pte-restart-fails.patch mm-madvise-use-folio_trylock-in-the-cold-pageout-pmd-split.patch