Re: [PATCH v10 12/37] mm: use folio_zero_user for user pages in post_alloc_hook

[Michael S. Tsirkin]

On Mon, Jun 08, 2026 at 04:53:14PM -0400, Gregory Price wrote:
> On Mon, Jun 08, 2026 at 04:30:46PM -0400, Michael S. Tsirkin wrote:
> > > 
> > > Please consider that this is arguably the most fundamental interface in
> > > in all of mm/.  All we're doing is going through the process of figuring
> > > out what changes here are reasonable while trying to meet your goal.
> > > 
> > > ~Gregory
> > 
> > I don't mind discarding all of this and doing something else completely,
> > but I dislike it that multiple people are apparently now angry that I
> 
> I wouldn't say anyone is angry, I think most folks are tripping on the
> complexity of the set - which has increased (at the request of others).
> 
> > don't address all the contradictory comments at the same time.
> 
> Such is life in mm/ :] - it's hard to known the entire state machine,
> and sometimes the contradictions aren't even wrong.
> 
> > I thought just sending a patchset to show how the result looks like
> > is easier than arguing about architecture, and would be helpful.
> > 
> 
> Notice: When folks argue implementation, they largely agree the
> end goal is useful.  I haven't seen anyone say your problem isn't
> real or that it shouldn't be addressed - just opinions on a particular
> path forward (which is utterly normal here).
> 
> Getting the right incantation of an API is really hard when the
> API being changes is something that underpins the entire kernel.
> 
> > I'm not pushing any of the mm rework, I was asked to do it,
> > myself I just want the ridiculously effective optimization in there.
> > 
> 
> As Lorenzo, David, and Matthew have said, the focus of the patch set
> does seem to have become unweildy (in part at the request of folks
> asking something be done differently).
> 
> What needs to be done now is to break it up into some pull-ahead 
> sets that are easier to review.  Having a brief RFC doc that lays out
> the set of patches might help clarify the confusion going on here,
> especially as new folks come in to ask "What's all this about?".
> 
> As a start:
> 
>   1) the user_addr and zeroing piece seems like a discrete
>      improvement worthy of its own set - aside from end goal.
> 
>      This is needed by your patch set, but was requested to
>      try to push us towards a more reasonable pattern for
>      folio_zero_user().

What I worry about is people can't agree what api they want.

Simply not being an mm maintainer, I don't really have the
perspective of what changes are envisioned down the road
and so what api makes sense for you guys.

I don't mind trying all kind of approaches, but it seems to
be past the point where people feel it's costing too much of
their time with all of these revisions.


>   2) There are a handful of patches that seem able to pull-ahead
>      (some of the mempolicy stuff), either as prep work for #1 or
>      just on their own.
> 
>      Some of these patches seem like latent bugs that aren't hit by
>      current users, but do seem to be doing something subtly wrong?

Right.

>   3) the final virtio piece seems like it should be entirely separate
>      once the core pieces are done.
> 
> It's not uncommon for core changes like this to take multiple prepatory
> sets over many major versions before the final feature lands.
> 
> ~Gregory