On Mon, Jun 08, 2026 at 12:09:19PM -0400, Gregory Price wrote: > 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.
I'd tuned out this awful series since it'd become apparent that my feedback wasn't going to be taken seriously. Good to know I shouldn't take it personally because he does it to you too. I think it's apparent that Michael has no understanding of the MM. So we should start again with the architecture. Let's look at the problem that he's trying to solve: - The hypervisor has zeroed the memory that it passes to the MM - But the MM then zeroes it again before passing it to userspace. - We want to avoid this Let's make sure that's the actual problem before going any further. Because I do have a design that will satisfy that without doing this insane level of invasive change, but if that's not the problem, there's no point wasting my time writing it up.
