Re: [PATCH v4] mm: introduce a new page type for page pool in page type

[Byungchul Park]

On Wed, May 13, 2026 at 02:06:06PM +0200, Dragos Tatulea wrote:
> On 13.05.26 11:36, David Hildenbrand (Arm) wrote:
> > On 5/13/26 11:26, Pedro Falcato wrote:
> >> On Wed, May 13, 2026 at 11:12:43AM +0200, Vlastimil Babka (SUSE) wrote:
> >>> On 5/13/26 11:00, Dragos Tatulea wrote:
> >>>>
> >>>>
> >>>>
> >>>> Seems like this patch broke tcp_mmap because
> >>>> validate_page_before_insert() returns -EINVAL due
> >>>> to a page having a type. Here's the full flow:
> >>>>
> >>>> getsockopt(TCP_ZEROCOPY_RECEIVE) returns -EINVAL because of the
> >>>> below flow in the kernel:
> >>>>
> >>>> tcp_zerocopy_receive()
> >>>> -> tcp_zerocopy_vm_insert_batch()
> >>>>   -> vm_insert_pages()
> >>>>     -> insert_pages()
> >>>>       -> insert_page_in_batch_locked()
> >>>>         -> validate_page_before_insert() returns -EINVAL
> >>>>            because page_has_type(page) is now true.
> >>>>
> >>>> The patch below fixes the issue. But is this a valid fix?
> >>>
> >>> Hmm the check traces back to commit 0ee930e6cafa0 "mm/memory.c: prevent
> >>> mapping typed pages to userspace"
> >>>
> >>>> Pages which use page_type must never be mapped to userspace as it would
> >>>> destroy their page type.  Add an explicit check for this instead of
> >>>> assuming that kernel drivers always get this right.
> >>>
> >>> So uh, this doesn't look good I think.
> >>
> >> Yep, you fundamentally can't map a page with a type as page type aliases with
> >> mapcount. Even with the given diff, just mapping it will increment the mapcount
> >> and wreak havoc. I think we need to revert this patch for now.
> >>
> >> I'm not sure what the long term plan for this would be. If page types are moved
> >> to memdesc types, then the two stop colliding and that could work. I don't know
> >> if that's Willy's plan, however.
> >>
> >> (then there's the other question: are page pool pages really folios? not really.
> >> they are mappable, but they aren't part of the page cache, or anon, nor are
> >> they in the LRU or have rmap capabilities. perhaps we need a different memdesc
> >> for those. we're one step away from reinventing class polymorphism from first
> >> principles ;)
> >
> > Zi Yan is working on this: non-folio pages would no longer mess with
> > rmap/mapcounts, and page table walking code will identify them to be non-folio
> > things to skip them.
> >
> > It will take a while, though ...
> >
> So do I get it right that the path forward here is to revert this commit [1]
> and wait until the work from Zi Yan is ready?

I think it's the best way for now.

	Byungchul
> 
> [1] db359fccf212 ("mm: introduce a new page type for page pool in page type")
> 
> Thanks,
> Dragos