On 02.06.25 11:33, David Hildenbrand wrote:
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1398,10 +1398,7 @@ static int insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,
}
entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
- if (pfn_t_devmap(pfn))
- entry = pmd_mkdevmap(entry);
- else
- entry = pmd_mkspecial(entry);
+ entry = pmd_mkspecial(entry);
if (write) {
I just stumbled over this, and I think there is something off here in
the PMD/PUD case.
vmf_insert_folio_pmd() does a folio_get() + folio_add_file_rmap_pmd().
But then, we go ahead and turn this into a special mapping by setting it
pmd_mkdevmap()/pmd_mkspecial().
Consequently, vm_normal_page_pmd() would ignore them, not following the
rules documented for vm_normal_page() and behaving differently than
vmf_insert_page_mkwrite()->insert_page().
folio_add_file_rmap_pmd() should never set these things special/devmap
in the first place :/
What am I missing?
Note that fs/dax.c calls vmf_insert_folio_pmd() for PMDs and
vmf_insert_page_mkwrite() for PTEs.
Consequently, PTEs will never be marked special (corner case, shared
zeropage), but PMDs would always.
Hm?
What an ugly piece of crap this pmd handling code is.
Just noting because I stumbled over that myself:
pmd_mkdevmap() does *not* imply pmd_special().
... in contrast to pte_mkdevmap(), which will imply pte_special().
--
Cheers,
David / dhildenb
