Thread (11 messages) flat view 11 messages, 2 authors, 16d ago

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

From: Tal Zussman <hidden>
Date: 2026-08-31 23:38:43
Also in: linux-mm, lkml

On 8/31/26 5:50 PM, Zi Yan wrote:
On Sun Aug 30, 2026 at 6:32 AM EDT, Tal Zussman wrote:
quoted
__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 <redacted>
---
 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.
quoted
 
 		/* Page flags must be visible before we make the page non-compound. */
 		smp_wmb();
-- 
Best Regards,
Yan, Zi
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help