Re: [PATCH v4 2/4] mm/huge_memory: copy file THPs at fork like copy_present_ptes() does

[Konstantin Khorenko <khorenko@virtuozzo.com>]

On 10/27/26 15:39, David Hildenbrand (Arm) wrote:
> Any reason we're not adding the vma_is_cow_mapping() check on the
> softleaf_is_device_private_write() path as well?
>
> (I think they are all anonymous ... just for consistency)

No reason, copy_nonpresent_pte() has it there too. Will add in v5.

> Is the fallthrough:
>
>       add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR)
>
> really expected?

Yes: copy_nonpresent_pte() counts migration and device private entries
in the child's RSS as well. File folios reach it now, so the hunk below
switches it to mm_counter(src_folio), as the PTE path does.
zap_huge_pmd_folio() subtracts a file folio from mm_counter_file(), so
MM_ANONPAGES there would leave the child's counters unbalanced.

>> +    bool writable;
>
> Why do we need this variable?

It copies __copy_present_ptes(), which snapshots pte_write() before
the uffd-rwp branch. Looking at it again, that branch only rewrites an
RWP marker, which is PAGE_NONE and never writable, and vm_page_prot of
a CoW mapping has no write bit either. So the snapshot looks redundant
both here and in __copy_present_ptes().

I'd keep it in this series so the PMD path matches the PTE one, and
drop it from both in the cleanup together with the gotos.

Kiryl, does that match your understanding of the PTE path?

>> +            goto copy_pmd;
>>      }
>
> Likely we should clean this up later to avoid the gotos.

No problem, but let's do it later, on top of this series.

And on your stable question in 3/4: v5 will carry Cc: stable on patches
1-3.
The backport to 6.12 won't apply as is, so I'll do the backports once we
get a failure mail on stable re-apply attempt.
(or I need to do backports in advance? Need an advice here.)

Thanks for the review!

--
Konstantin Khorenko