Re: [PATCH v7 09/31] mm: use folio_zero_user for user pages in post_alloc_hook

[Michael S. Tsirkin]

On Thu, May 14, 2026 at 02:56:54PM -0400, Gregory Price wrote:
> On Thu, May 14, 2026 at 02:00:31PM -0400, Michael S. Tsirkin wrote:
> > On Thu, May 14, 2026 at 09:49:33AM -0400, Gregory Price wrote:
> > 
> > There are calls with no __GFP_ZERO but they do not allocate userspace pages.
> > 
> >   - drm_pagemap.c: GFP_HIGHUSER -- no zero. But this is a DRM device
> >     page migration, the page content is preserved from the source.
> > 
> >   - test_hmm.c: GFP_HIGHUSER_MOVABLE -- no zero. Test driver, pages get
> >     content from device.
> > 
> >   - mm/ksm.c: GFP_HIGHUSER_MOVABLE -- no zero. KSM merges identical
> >     pages, content comes from the source page (copy).
> > 
> >   - mm/memory.c new_folio = GFP_HIGHUSER_MOVABLE
> >     - no zero. This is CoW, content is copied from old page.
> > 
> >   - mm/userfaultfd.c: GFP_HIGHUSER_MOVABLE - no zero. Content comes from userspace via userfaultfd.
> > 
> >   - arm64/fault.c: __GFP_ZEROTAGS not __GFP_ZERO. MTE tag zeroing, not page zeroing. Page is zeroed separately.
> > 
> 
> Right, so in all of these cases, it would be just as correct to pass
> USER_ADDR_NONE I imagine :]

Hmm. Are you sure? Isn't the address used for numa policy?

> i.e. the user address is irrelevant, and the caller is responsible for
>      sanitization before return if it's relevant.
> 
> Otherwise, passing (user_addr != -1) the buddy takes care of it for you.
> 
> Just an obvious security bonus to all of this, but by no means a
> requirement for your set.  Just an observation.
> 
> > 
> > I'd do this on top if possible.
> >
> 
> Yeah reasonable.
> 
> ~Gregory