On Mon, Jun 08, 2026 at 11:51:47PM +0200, David Hildenbrand (Arm) wrote: > On 6/8/26 23:16, Zi Yan wrote: > > There was Willy's comment in RFC v3 [1], which had 19 patches. Unfortunately, > he > no longer followed up to my initial push back and Michael's question later > [2]. > > That would have probably been the right time to wait for more discussion. > > RFC v4 had 22 patches with little replies. > v5 had 28 patches with little replies. > v6 had 30 patches with no replies. > v7 had 31 patches with little replies. > v8 had 37 patches with no replies. > > [1] https://lore.kernel.org/lkml/[email protected]/ > [2] > https://lore.kernel.org/lkml/[email protected]/ >
Hm, rewinding on this back to v3 here: https://lore.kernel.org/lkml/[email protected]/ You said: ``` Exactly, that's why I am saying that vma_alloc_folio() is the only external interface people should be using with a user address. ``` Going through the list of folio_zero_user references: Called unconditionally if a folio is acquired: fs/hugetlbfs/inode.c: folio_zero_user(folio, addr); mm/hugetlb.c: folio_zero_user(folio, vmf->real_address); mm/memfd.c: folio_zero_user(folio, 0); Called when user_alloc_needs_zeroing() and charging passes: mm/huge_memory.c: folio_zero_user(folio, addr); mm/memory.c: folio_zero_user(folio, vmf->address); No one outside mm/ should know about this interface at all. Arguably none of these should know about this interface either. The appropriate place for this logic appears to be: vma_alloc_folio alloc_hugetlb_folio alloc_hugetlb_folio_reserve The reason to sink it into the post_alloc_hook is to let the buddy decide whether the page actually needs to be zeroed (like the virtio situation) based on PG_zeroed or whatever. It seems like at a minimum moving the logic all the way into post_alloc_hook lets us actually delete folio_zero_user() as a published interface and move it entirely within page_alloc.c. The catch is user_alloc_needs_zeroing() coming along with it. ~Gregory
