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

[Dragos Tatulea]

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.

Thanks,
Dragos