On Tue, Apr 14, 2026 at 05:46:58PM +0200, David Hildenbrand (Arm) wrote: > On 4/14/26 12:29, Michael S. Tsirkin wrote: > > On Tue, Apr 14, 2026 at 11:04:04AM +0200, David Hildenbrand (Arm) wrote: > >> On 4/13/26 22:37, Michael S. Tsirkin wrote: > >>> > >>> I admit I only vaguely understand the core mm refactoring you are > >>> suggesting. > >>> > >> > >> Oh, I was hoping claude would figure that out for you. > > > > We figured it out together) > > :) > > [...] > > > > > > > Pretty much what I did, except I felt it is better to change the > > existing APIs. A bit more churn, but in return there's less of a chance > > we forget to pass the user address. > > > > Because, if we do, the result works fine on x86 but corrupts memory > > on other arches. > > Converting everything is probably cleaner long term, But there are many > instances where we just don't really have an address, or the address is > irrelevant, because we wouldn't care about the difference when zeroing. > > vma_alloc_folio() is the API to use when we have a VMA + address. > > But yeah, something that is harder to mess up would be nice.
Well ... I am making progress on this but it is very intrusive. Are we sure we do not want simply this, just maybe renaming the flags? For example: __GFP_PREZERO -> __GFP_ZERO_HINT - request a hint that the allocated page is zero And an API hiding the fact that the hint is in page->private. Hmm? > -- > Cheers, > > David
