On Tue, Apr 21, 2026 at 12:04:49PM +0200, David Hildenbrand (Arm) wrote: > On 4/21/26 04:38, Gregory Price wrote: > > On Mon, Apr 20, 2026 at 07:33:38PM -0400, Michael S. Tsirkin wrote: > >> On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote: > >> > >>> > >>> Which would *already* be the case of you use folio_alloc(GFP_ZERO) > >>> instead of magical vma_alloc_folio() + folio_zero_user(). > >>> > >>> I don't really see how vma_alloc_folio_hints() -- that also consumes the > >>> address -- is any better in that regard? > >> > >> By itself, it is not. But the issue is propagating the address from > >> there all over mm. If we miss even one place - we get a subtle cache > >> corruption on non x86. > >> > > > > Why does it need to propogate? > > > > Can we leave folio_zero_user() callers the same, but add a PG_zeroed > > check in folio_zero_user() that skips the zeroing (but not the cache > > flush) and clear the PG_zeroed bit? > > folio_zero_user() is just an abomination, really.
We can't completely replace it with GFP_ZERO though e.g. because hugetlbfs has its own pool and needs to zero that. > -- > Cheers, > > David
