Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages

[Gregory Price <gourry@gourry.net>]

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