mm: huge_memory: fix misused mapping_large_folio_support() for anon folios

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

mm: huge_memory: fix misused mapping_large_folio_support() for anon folios

When I did a large folios split test, a WARNING "[ 5059.122759][ T166]

Cannot split file folio to non-0 order" was triggered. But the test cases

are only for anonmous folios. while mapping_large_folio_support() is only

reasonable for page cache folios.

In split_huge_page_to_list_to_order(), the folio passed to

mapping_large_folio_support() maybe anonmous folio. The folio_test_anon()

check is missing. So the split of the anonmous THP is failed. This is

also the same for shmem_mapping(). We'd better add a check for both. But

the shmem_mapping() in __split_huge_page() is not involved, as for

anonmous folios, the end parameter is set to -1, so (head[i].index >= end)

is always false. shmem_mapping() is not called.

Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon

mapping, So we can detect the wrong use more easily.

THP folios maybe exist in the pagecache even the file system doesn't

support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is

enabled, khugepaged will try to collapse read-only file-backed pages to

THP. But the mapping does not actually support multi order large folios

properly.

Using /sys/kernel/debug/split_huge_pages to verify this, with this patch,

large anon THP is successfully split and the warning is ceased.