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

[Byungchul Park]

On Thu, May 14, 2026 at 11:24:36AM +0200, Dragos Tatulea wrote:
> On 14.05.26 10:54, Byungchul Park wrote:
> > 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.
> >
> Ack. Can you do it please? This is a more complicated revert and the risk that I
> mess it up is higher.

I will.

	Byungchul
> 
> Thanks,
> Dragos
> 
>