On Mon, Apr 20, 2026 at 10:38:19PM -0400, 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:
> > > On 4/20/26 14:51, Michael S. Tsirkin wrote:
> >
> > > > A lot of churn, and my concern is, if we miss even one
> > > > place, silent, subtle data corruption will result and only
> > > > on some arches (x86 will be fine).
> > >
> > > 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?
>
> Is this feasible?
I do not see how - this would require leaking the page flag out of the
buddy allocator.
> You don't eliminate the folio_zero_user(), but maybe we shouldn't?
>
> (a bit naive here - i haven't checked the PG_zeroed lifetime, i did
> see it overloads PG_private - so this might not be feasible)
>
> >
> > I also note that we need a flag for free in order to implement
> > balloon deflate as you asked. Here, I reused the hints.
> >
>
> I'd sooner just implement this as
>
> ___put_folio(folio, gfp_t)
>
> __put_folio(folio) { ___put_folio(folio, NULL); }
>
> And change the free path to take overloaded gfp flags.
> Some of the existing ones might even be useful as-is.
>
> It's essentially the same thing, but prevents a bunch of churn and
> saves us a new concept.
>
> optional gfp flags on free seem like genuinely useful interface for
> certain callers (definitely not all).
>
> ~Gregory
But we do not have a gfp_t flag meaning "this has been zeroed"
and when I proposed something similar in v1, David hated abusing
gfp flags for what is not an allocation property.
