mm: thp: deny THP for files on anonymous inodes

In the Linux kernel, the following vulnerability has been resolved:

mm: thp: deny THP for files on anonymous inodes

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:

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

Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all

anonymous inode files.