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
