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

[Zi Yan <ziy@nvidia.com>]

On 17 Nov 2025, at 22:33, Wei Yang wrote:

> On Mon, Nov 17, 2025 at 10:56:39AM -0500, Zi Yan wrote:
>> On 16 Nov 2025, at 20:22, Wei Yang wrote:
>>
>>> 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.
>>
>> Probably because the race is small, but a fix is still needed.
>> Likely commit 6a50c9b512f7 ("mm: huge_memory: fix misused
>> mapping_large_folio_support() for anon folios") introduced it, but please
>> double check.
>>
>
> After searching the history, it has four related commits.
>
> I listed here in timeline.
>
> [1] commit c010d47f107f609b9f4d6a103b6dfc53889049e9
>     Author: Zi Yan <ziy@nvidia.com>
>     Date:   Mon Feb 26 15:55:33 2024 -0500
>
>         mm: thp: split huge page to any lower order pages
>
> [2] commit 6a50c9b512f7734bc356f4bd47885a6f7c98491a (HEAD -> tmp)
>     Author: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>     Date:   Fri Jun 7 17:40:48 2024 +0800
>
>         mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
>
> [3] commit 9b2f764933eb5e3ac9ebba26e3341529219c4401 (refs/bisect/bad)
>     Author: Zi Yan <ziy@nvidia.com>
>     Date:   Wed Jan 22 11:19:27 2025 -0500
>
>         mm/huge_memory: allow split shmem large folio to any lower order
>
> [4] commit 58729c04cf1092b87aeef0bf0998c9e2e4771133 (HEAD -> tmp)
>     Author: Zi Yan <ziy@nvidia.com>
>     Date:   Fri Mar 7 12:39:57 2025 -0500
>
>         mm/huge_memory: add buddy allocator like (non-uniform) folio_split()
>
> So I think the fix tag should be [1], right?

I think so.

>
> And do we need cc stable?

Yes, please.

Thanks.

Best Regards,
Yan, Zi