Re: [PATCH] mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios

[Zi Yan]

On 5 Jun 2026, at 5:22, David Hildenbrand (Arm) wrote:

> On 6/5/26 07:17, Alistair Popple wrote:
>> On 2026-05-15 at 10:09 +1000, Balbir Singh <balbirs@xxxxxxxxxx> wrote...
>>> On 4/9/26 17:52, David Hildenbrand (Arm) wrote:
>>>>
>>>> Hm, what if secretmem folio just got truncated? I hate to rely on some
>>>> handling in the caller to detect truncation differently during GUP-fast,
>>>> but this function returning "true".
>>>>
>>>
>>> Can secretmem folios be truncated? I assume you are referring to
>>> ftruncate(), I am looking at the setattr implementation of secretmem
>>> and it does not seem like it can be truncated.
>>>
>>>> Zi is working on a way to distinguish folios from non-folio things: that
>>>> we can identify whatever was added through vm_insert_page().
>>>>
>>>> Because that's really the key problem here: vm_insert_page() pages are
>>>> not actually folios, they just look like a folio today, but looking at
>>>> fields like ->mapping does not make any sense.
>>>>
>>>
>>> I still think this is a short term fix worth having until we get
>>> Zi's fixes
>>
>> Agreed - this clearly results in a performance regression and we have customers
>> reporting it as such. I think Zi might be out of the office atm but when I last
>> spoke to him he agreed this fix should go in for now and his approach will come
>> later.
>
> He should be back now. But yeah, let's get this fix in.

Right, I will work on my solution soon. Meanwhile, this change
is simpler and can be easily back ported.

BTW, should it be back ported to older kernels?

Best Regards,
Yan, Zi