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

[Alistair Popple]

On 2026-06-06 at 02:20 +1000, Zi Yan <ziy@xxxxxxxxxx> wrote...
> 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.

Thanks.

> BTW, should it be back ported to older kernels?

Yes to any with f002882ca369 ("mm: merge folio_is_secretmem() and
folio_fast_pin_allowed() into gup_fast_folio_allowed()") - we have got bug
reports as a result of the lowered perf that commit causes.

 - Alistair

> Best Regards,
> Yan, Zi