On 6/8/26 12:23, Lorenzo Stoakes wrote: > I noticed this patch, again, sneaks in some additional code changes that > are not mentioned in the commit message and seem irrelevant to the patch. > > Not sure if the AI is doing this, but please don't do that. > > On Mon, Jun 08, 2026 at 04:35:17AM -0400, Michael S. Tsirkin wrote: >> Thread a user virtual address from vma_alloc_folio() down through >> the page allocator to post_alloc_hook(). This is plumbing >> preparation for a subsequent patch that will use user_addr to >> call folio_zero_user() for cache-friendly zeroing of user pages. > > This feels like very weak justification for code that massively changes mm > code and makes it all much worse. > >> >> The user_addr is stored in struct alloc_context and flows through: >> vma_alloc_folio -> folio_alloc_mpol -> __alloc_pages_mpol -> >> __alloc_frozen_pages -> get_page_from_freelist -> prep_new_page -> >> post_alloc_hook > > Is this the only relevant code path? You're changing a TON of code here > that will have multiple different code paths? > >> >> USER_ADDR_NONE ((unsigned long)-1) is used for non-user >> allocations, since address 0 is a valid userspace mapping. > > Ugh god, so now we're passing a user address through allocation paths that > might not even be aware of this or be allocating memory at a point when the > mapping is known?
The original ideas was to do this only with internal interfaces. I think I raised before to leave hugetlb alone for now. Fundamentally, user_alloc_needs_zeroing() is something we should get rid of, to just be able use __GFP_ZERO and do zeroing at exactly one place. The question is how to pass that information (user_addr) through internal APIs. I previously said, that ideally we'd end up with a folio allocation interface in mm/page_alloc.c, from where we could get this done more cleanly internally. But I don't want what the previous proposals did: use GFP flags+leak state or return magic "zeroed" flags. -- Cheers, David
