On Fri, May 15, 2026 at 11:39:20AM -0400, Gregory Price wrote:
> On Thu, May 14, 2026 at 03:08:13PM -0400, Michael S. Tsirkin wrote:
> > 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?
> > 
> 
> You said "They do not allocate userspace pages" - so wouldn't uaddr be
> USER_ADDR_NONE anyway?

That part was wrong.

> 
> Even if they do allocate userspace pages, they weren't passing
> __GFP_ZERO before, so either:
> 
>   1) They did not depend on the buddy to do zeroing before, and
>      user_addr is just a dead variable in those cases anyway.
> 
>      or
> 
>   2) There is a bug, and they should be zeroing the page.


IIUC, it's neither. Consider CoW: yes we are allocating a new page
for userspace, but no we do not need to zero: we are copying
data on write.



> I just see an interesting hardening opportunity.
> 
> Not suggesting you actually implement this, to be clear, maybe just
> documenting the idea on the thread as a potential follow up.
> 
> ~Gregory


Reply via email to