Re: [PATCH v3 09/18] mm/huge_memory: move anon_vma and filemap management into split helpers

From: David Hildenbrand (Arm)

Date: Mon Sep 07 2026 - 08:41:02 EST


On 8/30/26 17:23, Kairui Song wrote:
> On Thu, Aug 27, 2026 at 06:36:18PM +0800, David Hildenbrand (Arm) wrote:
>> On 8/20/26 20:55, Kairui Song via B4 Relay wrote:
>>> From: Kairui Song <kasong@xxxxxxxxxxx>
>>>
>>> Only anon split needs vma info, and only file split needs the filemap
>>> handling. Move the related code into separate helpers so they are
>>> genuinely more self-contained.
>>
>> This patch seems to do more than that, like relocating the
>> folio_expected_ref_count check (and duplicating it, which is not so nice).
>
> We can keep it where it is right now, but this patch is moving the
> anon_vma_lock_write and i_mmap_lock_read into the two anon / file
> helpers seperately, so keeping the folio_expected_ref_count check
> outside and before the helper call will cause a potential higher
> false positive / negative rate of this check? Leads to unnecessary
> call to unmap_folio.
>
> How about moving the folio_expected_ref_count check into
> unmap_folio since the purpose of the ref check is to avoid
> unnecessary unmap? No more duplication that way.

I think the crucial part (for anon folios) is to also check after we unmapped.

See __folio_migrate_mapping(), where we don't do the !folio_ref_freeze() in case
we tun into the !mapping scenario.

--
Cheers,

David