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? If not, then this subtle complexity is now a tripping hazard. Is there some combination of arguments here that should just outright fail if a user attempts it? > > 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). 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). 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
