Re: [Patch v3 2/2] mm/huge_memory: merge uniform_split_supported() and non_uniform_split_supported()

[Wei Yang <richard.weiyang@gmail.com>]

On Thu, Nov 06, 2025 at 03:41:55AM +0000, Wei Yang wrote:
>The functions uniform_split_supported() and
>non_uniform_split_supported() share significantly similar logic.
>
>The only functional difference is that uniform_split_supported()
>includes an additional check on the requested @new_order.
>
>The reason for this check comes from the following two aspects:
>
>  * some file system or swap cache just supports order-0 folio
>  * the behavioral difference between uniform/non-uniform split
>
>The behavioral difference between uniform split and non-uniform:
>
>  * uniform split splits folio directly to @new_order
>  * non-uniform split creates after-split folios with orders from
>    folio_order(folio) - 1 to new_order.
>
>This means for non-uniform split or !new_order split we should check the
>file system and swap cache respectively.
>
>This commit unifies the logic and merge the two functions into a single
>combined helper, removing redundant code and simplifying the split
>support checking mechanism.
>
>Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>Cc: Zi Yan <ziy@nvidia.com>
>Cc: "David Hildenbrand (Red Hat)" <david@kernel.org>
>
[...]
>-/* See comments in non_uniform_split_supported() */
>-bool uniform_split_supported(struct folio *folio, unsigned int new_order,
>-		bool warns)
>-{
>-	if (folio_test_anon(folio)) {
>-		VM_WARN_ONCE(warns && new_order == 1,
>-				"Cannot split to order-1 folio");
>-		if (new_order == 1)
>-			return false;
>-	} else  if (new_order) {
>+	} 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)) {

After re-scan the code, I found we may have a NULL pointer dereference here.

We bail out if folio->mapping == NULL in __folio_split(), which means it is
possible to be NULL. But we access mapping->flags here.

Looks there is no bug report yet, so I am not sure it worth a separate fix to
original code.

>+			/*
>+			 * 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.
>+			 */
> 			VM_WARN_ONCE(warns,
> 				"Cannot split file folio to non-0 order");
> 			return false;
> 		}
> 	}
> 
>-	if (new_order && folio_test_swapcache(folio)) {
>+	/*
>+	 * swapcache folio could only be split to order 0
>+	 *
>+	 * non-uniform split creates after-split folios with orders from
>+	 * folio_order(folio) - 1 to new_order, making it not suitable for any
>+	 * swapcache folio split. Only uniform split to order-0 can be used
>+	 * here.
>+	 */
>+	if ((split_type == SPLIT_TYPE_NON_UNIFORM || new_order) && folio_test_swapcache(folio)) {
> 		VM_WARN_ONCE(warns,
> 			"Cannot split swapcache folio to non-0 order");
> 		return false;
>@@ -3794,11 +3787,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
> 	if (new_order >= old_order)
> 		return -EINVAL;
> 
>-	if (split_type == SPLIT_TYPE_UNIFORM && !uniform_split_supported(folio, new_order, true))
>-		return -EINVAL;
>-
>-	if (split_type == SPLIT_TYPE_NON_UNIFORM &&
>-	    !non_uniform_split_supported(folio, new_order, true))
>+	if (!folio_split_supported(folio, new_order, split_type, /* warn = */ true))
> 		return -EINVAL;
> 
> 	is_hzp = is_huge_zero_folio(folio);
>-- 
>2.34.1

-- 
Wei Yang
Help you, Help me