Re: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in file_thp_enabled()

[Deepanshu Kartikey]

On Fri, Feb 13, 2026 at 3:49 AM Ackerley Tng <ackerleytng@xxxxxxxxxx> wrote:
>
> "David Hildenbrand (Arm)" <david@xxxxxxxxxx> writes:
>
> Going to try and summarize the findings/discussions here, copying from a
> few earlier emails. David, you can jump directly to [Question].
>
> > On 2/11/26 16:38, Ackerley Tng wrote:
> >> "David Hildenbrand (Arm)" <david@xxxxxxxxxx> writes:
> >>
> >>> On 2/11/26 00:00, Ackerley Tng wrote:
> >>>> "David Hildenbrand (Arm)" <david@xxxxxxxxxx> writes:
> >>>>
> >>>>
> >>>> Seems like on 5.15.199 there's a hugepage_vma_check(), which will return
> >>>> false since secretmem has vma->vm_ops defined [1], so secretmem VMAs are
> >>>> skipped.
> >>>
> >>> Are you sure? We check for CONFIG_READ_ONLY_THP_FOR_FS before that:
> >>>
> >>
> >> Ah... I was working on a reproducer then I realized 5.15 doesn't have
> >> MADV_COLLAPSE, then I tried to hack in an ioctl to trigger
> >> khugepaged. That turned out to be awkward but it got me to look at
> >> hugepage_vma_check(), and then I went down the rabbit hole to keep
> >> looking for the similar check function throughout the other stable
> >> kernels... and amongst all of that forgot that
> >> CONFIG_READ_ONLY_THP_FOR_FS was unset :(
> >>
> >> You're probably right about VM_EXEC.
> >>
>
> [Bug]
> khugepaged (and MADV_COLLAPSE) will try to collapse secretmem pages with
> MADV_HUGEPAGE applied. There is no crash, but there is a false memory
> failure printout that looks like
>
>     [ 1068.322578] Memory failure: 0x106d96f: recovery action for
> clean unevictable LRU page: Recovered
>
> The correct Fixes tag should be:
>
>     Fixes: 7fbb5e188248 ("mm: remove VM_EXEC requirement for THP eligibility")
>
> I was able to reproduce this on 6.12, 6.18 and HEAD
>
> [Stable Backports]
> The first stable version this affects is 6.12.
>
> In 6.12, S_ANON_INODE does not yet exist, so I think in
> file_thp_enabled() we can return false if vma_is_secretmem(vma).
>
> 6.18 needs a fix for both secretmem and guest_memfd.
>
> [Solution]
> For 6.18 and later, David's suggestion of using IS_ANON_FILE() seems to
> work. This affects more filesystems than just secretmem and guest_memfd
> though.
>
> [Question]
> I'm not familiar with the concept of anonymous inodes. What does that
> entail? Why is it suitable in deciding THP eligibility?
>
> [Next Steps]
> I'm going to be traveling over the next few weeks, so perhaps Deepanshu
> can help with the fixup patches for 6.12, 6.18 and HEAD?
>

Hi David,

Thanks Ackerley for the reproducer and analysis. Since Ackerley will be
traveling, I can take this forward.

Here is the approach I am planning:

For HEAD / 6.18:
  - Add IS_ANON_FILE(inode) check in file_thp_enabled() as you suggested
  - Fixes: 7fbb5e188248 ("mm: remove VM_EXEC requirement for THP eligibility")
  - Cc: stable@xxxxxxxxxxxxxxx

For 6.12 stable backport:
  - IS_ANON_FILE / S_ANON_INODE does not exist in 6.12, so use
    mapping_inaccessible() || secretmem_mapping() in file_thp_enabled()
    instead