On Thu, Mar 26, 2026 at 09:42:51PM -0400, Zi Yan wrote: > Without READ_ONLY_THP_FOR_FS, large file-backed folios cannot be created by > a FS without large folio support. The check is no longer needed. > > Signed-off-by: Zi Yan <[email protected]>
Seems legitimate, so: Reviewed-by: Lorenzo Stoakes (Oracle) <[email protected]> > --- > mm/huge_memory.c | 22 ---------------------- > 1 file changed, 22 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 1da1467328a3..30eddcbf86f1 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -3732,28 +3732,6 @@ int folio_check_splittable(struct folio *folio, > unsigned int new_order, > /* order-1 is not supported for anonymous THP. */ > if (new_order == 1) > return -EINVAL; > - } else if (split_type == SPLIT_TYPE_NON_UNIFORM || new_order) { > - if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && > - !mapping_large_folio_support(folio->mapping)) { > - /* > - * We can always split a folio down to a single page > - * (new_order == 0) uniformly. > - * > - * For any other scenario > - * a) uniform split targeting a large folio > - * (new_order > 0) > - * b) any non-uniform split > - * we must confirm that the file system supports large > - * folios. > - * > - * Note that we might still have THPs in such > - * mappings, which is created from khugepaged when > - * CONFIG_READ_ONLY_THP_FOR_FS is enabled. But in that > - * case, the mapping does not actually support large > - * folios properly. > - */ > - return -EINVAL; > - } > } > > /* > -- > 2.43.0 >
