Re: [PATCH v2 1/2] mm/huge_memory: take a reference on a folio PUD copied by fork

[David Hildenbrand (Arm)]

On 11/5/26 21:19, Zi Yan wrote:
> On Thu Nov 5, 2026 at 12:00 PM EST, Konstantin Khorenko wrote:
>> Device DAX maps its memory with vmf_insert_folio_pud(), which takes a
>> folio reference, adds a PUD rmap and accounts the pages to the mm.
>> zap_huge_pud() drops all three, but copy_huge_pud() copies the PUD into
>> the child without taking any of them. Each child's unmap then drops
>> what the parent took:
>>
>> - the folio is a reference short, so with two children its refcount
>>   drops to zero and free_zone_device_folio() runs while the parent
>>   still maps it;
>> - the child's file counter goes negative, "Bad rss-counter state" when
>>   its mm is freed;
>> - the parent's unmap drives the entire mapcount below zero.
>>
>> fork copies the page tables of a device DAX mapping that has a guard
>> region, and commit f807123d578d ("mm: allow guard regions in file-backed
>> and read-only mappings") allowed MADV_GUARD_INSTALL there.
>>
>> Take the reference, the rmap and the counter for a PUD that
>> vm_normal_page_pud() resolves to a page, as copy_present_ptes() does for
>> a PTE, with a new folio_dup_file_rmap_pud() helper. copy_huge_pud() now
>> needs both VMAs, so pass only them and take the mms from them.
>>
>> Fixes: aed877c2b425 ("device/dax: properly refcount device dax pages when mapping")
>> Suggested-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Konstantin Khorenko <khorenko@xxxxxxxxxxxxx>
>> ---
>>  include/linux/huge_mm.h |  5 ++---
>>  include/linux/rmap.h    | 22 ++++++++++++++++++++++
>>  mm/huge_memory.c        | 27 +++++++++++++++++++--------
>>  mm/memory.c             |  4 +---
>>  4 files changed, 44 insertions(+), 14 deletions(-)
>>
> 
> I assume this supersedes David's version[1], which uses
> folio_add_file_rmap_pud().
> 
> [1] https://lore.kernel.org/all/20261031-fixes_core-v3-11-d6437171ecc3@xxxxxxxxxx/

Ugh, I thought I dropped it to wait for this one here. But turns out the flood
of patches confused me :( (hoping I didn't drop another one by mistake)

It's already part of the fixes PULL request:

https://lore.kernel.org/linux-mm/20261105084704.5703-1-david@xxxxxxxxxx/

Konstantin, sorry! Can you send a follow up to introduce+use the dup variant?

-- 
Cheers,

David