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

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

On 2/13/26 06:02, Deepanshu Kartikey wrote:
> On Fri, Feb 13, 2026 at 3:49 AM Ackerley Tng <ackerleytng@google.com> wrote:
>>
>> "David Hildenbrand (Arm)" <david@kernel.org> writes:
>>
>> Going to try and summarize the findings/discussions here, copying from a
>> few earlier emails. David, you can jump directly to [Question].
>>
>>
>> [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@vger.kernel.org

Right. Please link the mail with Ackerley's reproducers and carefully 
describe the implications. Then describe how anon inodes never pass the 
"opened writable" check and that the clean thing to do is to revert to 
disallowing anon inodes altogether.

Also describe how secretmem is not affected upstream, but triggers the 
confusing memory failure errors.

> 
> 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

I think secretmem_mapping() is sufficient there given that guest_memfd 
does not apply yet.

But we can discuss the details about the backport once the upstream fix 
is in.

Thanks!

-- 
Cheers,

David