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?
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
