On Mon, Jun 08, 2026 at 01:00:17PM +0100, Lorenzo Stoakes wrote: > On Mon, Jun 08, 2026 at 04:37:48AM -0400, Michael S. Tsirkin wrote: > > > > void post_alloc_hook(struct page *page, unsigned int order, gfp_t > > gfp_flags, > > - unsigned long user_addr); > > + bool zeroed, unsigned long user_addr); > > host_zeroed or something would be more appropriate no? > > But in general do we need to propagate this around, can't we derive it from > the page zeroed flag? > > It's really confusing as to _which_ zeroing this refers to, it seems the > only one relevant here is the VM host zeroing but that's completely > non-obvious and now everybody using these functions with the extra param > will simply have to happen to know this. > > If we could find a way to avoid this propagation that'd be ideal. > > Failing that, making it clear this is _only_ for vm host zeroing would be > better, but then maybe we need to think about how we could encode this in > some other way, e.g. passing alloc_context perhaps? >
This is unaddressed feedback from 3 version ago: https://lore.kernel.org/linux-mm/agXYbcuQYooG74pb@gourry-fedora-PF4VCD3F/ We can infer all of this from snapshotted page flags and propogate those around. This is infinitely more useful than just a single flag being pulled out into a boolean, and more extensible. void post_alloc_hook(struct page *page, usigned int order, gfp_t gfp_flags, uint64_t pg_alloc_flags, unsigned long user_addr); ^^^ page_alloc.c internal falgs only Once the allocator gets a page it wants to return, it can take a snapshot of the flags at that point, and then doodle all over the flags as it goes through the page setup prior to return (include the post hook). Haven't seen a reason why this shouldn't be done this way. ~Gregory
