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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/5/26 07:17, Alistair Popple wrote:
> On 2026-05-15 at 10:09 +1000, Balbir Singh <balbirs@nvidia.com> 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.

-- 
Cheers,

David