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
