On Mon, Jun 08, 2026 at 11:53:40AM -0400, Gregory Price wrote: > On Mon, Jun 08, 2026 at 12:23:07PM +0100, Lorenzo Stoakes wrote: > > On Mon, Jun 08, 2026 at 04:36:38AM -0400, Michael S. Tsirkin wrote: > > > > > + * user_addr != USER_ADDR_NONE implies sleepable > > > + * context (user page fault). > > > > Can you safely assume that? Also inferring which context we are in from this > > parameter seems risky. > > > > It seems to me that you're now making it such that kernel developers: > > > > - Have to know when and when not to specify a user address, and under what > > circumstances we might consider that to be mapped. > > > > - Need to know to do this correctly for aliasing architectures or have > > silent > > correctness issues. > > > > - Need to take context into account when specifying this. > > > > We definitely need to find a simpler way to do this! > > > > This feedback was poked at in earlier versions. There's a tension > between keeping the old interface as-is, having explicit interfaces > for something like this, and the state of a page inside the > allocator vs outside. > > Double-plus complicated by the fact that we're trying to reason about > two allocators at once: host and guest. > > It seems it has gotten a bit more complicated since then (I missed this > "sleepable context" bit, not sure if it was there on prior versions). > > 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. You are saying it's bad? It's pretty fundamental to the idea of moving zeroing into the allocator, I feel. -- MST
