Re: [PATCH v2] mm: thp: deny THP for files on anonymous inodes

[Ackerley Tng <ackerleytng@google.com>]

Lance Yang <lance.yang@linux.dev> writes:

> On 2026/2/14 08:15, Deepanshu Kartikey wrote:
>> file_thp_enabled() incorrectly allows THP for files on anonymous inodes
>> (e.g. guest_memfd and secretmem). These files are created via
>> alloc_file_pseudo(), which does not call get_write_access() and leaves
>> inode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being
>> true, they appear as read-only regular files when
>> CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP
>> collapse.
>>
>> Anonymous inodes can never pass the inode_is_open_for_write() check
>> since their i_writecount is never incremented through the normal VFS
>> open path. The right thing to do is to exclude them from THP eligibility
>> altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real
>> filesystem files (e.g. shared libraries), not for pseudo-filesystem
>> inodes.
>>
>> For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create
>> large folios in the page cache via the collapse path, but the
>> guest_memfd fault handler does not support large folios. This triggers
>> WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().
>>
>> For secretmem, collapse_file() tries to copy page contents through the
>> direct map, but secretmem pages are removed from the direct map. This
>> can result in a kernel crash:
>
> Good catch, thanks!
>
> For secretmem, file_thp_enabled() can incorrectly return true
> (i_writecount=0, S_ISREG=1), so the mapping becomes eligible for file
> THP collapse ...
>
> However, if any folio is dirty, collapse bails out early with
> SCAN_PAGE_DIRTY_OR_WRITEBACK, as secretmem doesn't support normal
> writeback, IIUC.
>

Yup! In the reproducers [1] I had to try to avoid setting the dirty flag
on the pages.

[1] https://lore.kernel.org/linux-mm/CAEvNRgHegcz3ro35ixkDw39ES8=U6rs6S7iP0gkR9enr7HoGtA@mail.gmail.com

>>
>>      BUG: unable to handle page fault for address: ffff88810284d000
>>      RIP: 0010:memcpy_orig+0x16/0x130
>>      Call Trace:
>>       collapse_file
>>       hpage_collapse_scan_file
>>       madvise_collapse
>>
>> Secretmem is not affected by the crash on upstream as the memory failure
>> recovery handles the failed copy gracefully, but it still triggers
>> confusing false memory failure reports:
>>
>>      Memory failure: 0x106d96f: recovery action for clean unevictable
>>      LRU page: Recovered
>
> Right. On my setup, that would hit SCAN_COPY_MC in
> hpage_collapse_scan_file()
> rather than a hard crash.
>

Deepanshu, were you able to trigger a hard crash on some earlier kernel?
I only saw this false memory failure log.

>>
>> Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all
>> anonymous inode files.
>>
>> Link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
>> Link: https://lore.kernel.org/linux-mm/CAEvNRgHegcz3ro35ixkDw39ES8=U6rs6S7iP0gkR9enr7HoGtA@mail.gmail.com
>> Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44
>> Fixes: 7fbb5e188248 ("mm: remove VM_EXEC requirement for THP eligibility")
>> Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
>> ---
>
> Confirmed that file_thp_enabled() is working as expected now with this fix.
>
> Tested-by: Lance Yang <lance.yang@linux.dev>
>
>
> Cheers,
> Lance