Re: [PATCH] mm/memfd: clear hugetlb pages on allocation

[David Hildenbrand (Red Hat)]

On 12.11.25 10:13, Oscar Salvador wrote:
> On Tue, Nov 11, 2025 at 10:55:03PM -0800, Hugh Dickins wrote:
> > Thanks a lot, Deepanshu and syzbot: this sounds horrid, and important
> > to fix very soon; and wlll need a Fixes tag (with stable Cc'ed when
> > the fix goes into mm.git), I presume it's
> >
> > Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios")
> >
> > But although my name appears against mm/memfd.c, the truth is I know
> > little of hugetlb (maintainers now addressed), and when its folios
> > are supposed to get zeroed (would a __GFP_ZERO somewhere be better?).
> >
> > I was puzzled by how udmabuf came into the picture, since hugetlbfs
> > has always supported the read (not write) system call: but see now
> > that there is this surprising backdoor into the hugetlb subsystem,
> > via memfd and GUP pinning.
> >
> > And where does that folio get marked uptodate, or is "uptodate"
> > irrelevant on hugetlbfs?  Are the right locks taken, or could
> > there be races when adding to hugetlbfs cache in this way?
>
> Thanks Hugh for raising this up.
>
> memfd_alloc_folio() seems to try to recreate what hugetlb_no_page()
> would do (slightly different though).

Can we factor that out to merge both paths?

> The thing is that as far as I know, we should grab hugetlb mutex before
> trying to add a new page in the pagecache, per comment in
> hugetlb_fault():
>
>   "
>     /*
>      * Serialize hugepage allocation and instantiation, so that we don't
>      * get spurious allocation failures if two CPUs race to instantiate
>      * the same page in the page cache.
>      */
>   "
>
> and at least that is what all callers of hugetlb_add_to_page_cache() do
> at this moment, all except memfd_alloc_folio(), so I guess this one
> needs fixing.
>
> Regarding the uptodate question, I do not see what is special about this situation
> that we would not need it.
> We seem to be marking the folio uptodate every time we do allocate a folio __and__
> before adding it into the pagecache (which is expected, right?).

Right, at least filemap.c heavily depends on it being set (I don't think 
hugetlb itself needs it).

> Now, for the GFP_ZERO question.
> This one is nasty.
> hugetlb_reserve_pages() will allocate surplus folios without zeroing, but those
> will be zeroed in the faulting path before mapping them into userspace pagetables
> (see folio_zero_user() in hugetlb_no_page()).
> So unless I am missing something we need to zero them in this case as well.

I assume we want to avoid GFP_ZERO and use folio_zero_user(), which is 
optimized for zeroing huge/gigantic pages.


--
Cheers

David