Re: [PATCH 2/8] mm/huge_memory: use folio_swap_entry() when splitting a swapcache folio

[Tal Zussman]

On 8/31/26 5:50 PM, Zi Yan wrote:
> On Sun Aug 30, 2026 at 6:32 AM EDT, Tal Zussman wrote:
>> __split_folio_to_order() open-codes the swap entry computation for the
>> split-out folios. Use folio_swap_entry() instead.
>>
>> No functional change.
>>
>> Signed-off-by: Tal Zussman <tz2294@xxxxxxxxxxxx>
>> ---
>>  mm/huge_memory.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 54494c3fa983..03287f995d92 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3760,7 +3760,7 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>  		VM_WARN_ON_ONCE_PAGE(new_folio->private, new_head);
>>  
>>  		if (folio_test_swapcache(folio))
>> -			new_folio->swap.val = folio->swap.val + i;
>> +			new_folio->swap = folio_swap_entry(folio, i);
> 
> folio_swap_entry() checks folio_nr_pages(folio) internally.
> folio->_nr_pages is in first tail page of folio. If new_order is 0, it
> is basically checking memcg_data in the first new_folio. And after first
> iteration, folio->_nr_page will be clobbered. Without
> NR_PAGES_IN_LARGE_FOLIO, folio_nr_pages() is derived from folio_order(),
> which is in folio->_flags_1. It can have the same issue.
> 
> Please keep it open coded. You can add a comment like "during split,
> not all folio fields are avaialbe, open code the swap calculation".
> 

Thanks, I'll drop this change.

I was debating whether the warning was worth adding. It'd be nice to
avoid accessing swap.val directly and abstract it away, but given that
that's done in a few other places too, open-coding it is fine.

>>  
>>  		/* Page flags must be visible before we make the page non-compound. */
>>  		smp_wmb();
> 
> -- 
> Best Regards,
> Yan, Zi
>