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:16:53PM -0400, Gregory Price wrote:
> On Mon, Jun 08, 2026 at 03:45:58PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jun 08, 2026 at 11:53:40AM -0400, Gregory Price wrote:
> > > 
> > > If `user_addr` is now implying anything other than exactly: "This needs
> > > to be zeroed / caches flushed", then this is bad.
> > > 
> > > ~Gregory
> > 
> > Well if you do folio_zero_user in a non sleepable context then things
> > are not going to work. So combining e.g. GFP_ATOMIC and GFP_ZERO and
> > user_addr all together is not a good idea.
> >
> 
> Can you say whether (GFP_ATOMIC | GFP_ZERO) w/o user_addr has the same
> issue?

I don't think it is because it does not call folio_zero_user, right?

>  If not, then this subtle complexity is now a tripping hazard.

Yes.

> Is there some combination of arguments here that should just outright
> fail if a user attempts it?

__GFP_DIRECT_RECLAIM at least.

> >
> > You are saying it's bad? It's pretty fundamental to the idea of moving
> > zeroing into the allocator, I feel.
> > 
> 
> I'm saying having to infer that safety state from the cobbling of those
> things together is not a good pattern (at least as-is).

Understood. Don't have a better idea, yet.

> If the introduction of user_addr into the mix is the thing that causes
> us to have to infer safety, then there's an argument the page allocator
> shouldn't handle that operation (in this case: user_addr cache flush).

It's not just the flush, we are also trying to use that to optimize
zeroing.

> 
> 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
don't address all the contradictory comments at the same time.
I thought just sending a patchset to show how the result looks like
is easier than arguing about architecture, and would be helpful.

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.


-- 
MST