Re: [RESEND] Re: [PATCH RFC v3 4/4] mm: add PMD-level huge page support for remap_pfn_range()

["David Hildenbrand (Arm)" <david@kernel.org>]

>>> +			pte_t entry;
>>> +
>>> +			if (!pmd_special(old_pmd)) {
>>
>> If you are using pmd_special(), you are doing something wrong.
>>
>> Hint: vm_normal_page_pmd() is usually what you want.
> 
> Spot on.
> 
> While looking into applying vm_normal_folio_pmd() here to avoid the
> magical VMA checks, I realized that both __split_huge_pmd_locked() and
> copy_huge_pmd() currently suffer from the same !vma_is_anonymous(vma)
> top-level entanglement.

Yes, that code is an absolute mess.

> I think these functions could benefit from a
> structural refactoring similar to what Lorenzo is currently doing in
> zap_huge_pmd().
> 
> My idea is to flatten both functions into a pmd_present()-driven
> decision tree:

Likely similar to how we handle PTEs.

> 1. Branch strictly on pmd_present().
> 2. For present PMDs, use vm_normal_folio_pmd() as the single source of
> truth.
> 3. If !folio (and not a huge zero page), it cleanly identifies special
> mappings (like PFNMAPs) without relying on vma_is_special_huge(). We can
> handle the split/copy directly and return early.
> 4. Otherwise, proceed with the normal Anon/File THP logic, or handle
> non-present migration entries in the !pmd_present() branch.

Yes, that sounds about right.

> 
> I have drafted two preparation patches demonstrating this approach and
> appended the diffs at the end of this email. Does this direction look
> reasonable to you? If so, I will iron out the implementation details and
> include these refactoring patches in my upcoming v4 series.
> 

Yes, sounds like nice cleanups.

Maybe the code could then benefit from moving the present vs. non-present
handling into separate functions? Just a thought.

-- 
Cheers,

David