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

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

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?

And do we need cc stable?

-- 
Wei Yang
Help you, Help me