Re: [PATCH 00/15] mm: eliminate &folio->page references in mm/

[David Hildenbrand (Arm)]

On 9/29/26 23:51, Nilay Vaish wrote:
> As part of the memdescs effort to separate struct folio from struct page
> and allocate struct folio dynamically [1], struct folio will no longer
> embed a struct page member (folio->page), and the address of a struct
> folio will no longer equal the address of its head struct page in
> vmemmap.
> 
> This series eliminates all but one of the remaining &folio->page
> references across mm/*.c (25 files) by converting them to:

I recall that Willy mentioned at some point that when changing this we
actually have to think about what the right thing to do is. As &folio->page
can serve as a reminder that something needs a proper solution instead of a
mechanical change.

So while folio_page(folio, 0) is the mechanical change, a much more
often we'll have to ask us what the actual future-proof thing is.


For example:

diff --git a/mm/migrate.c b/mm/migrate.c
index 7bdcdb57652f..b027c938d830 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -266,8 +266,8 @@ void putback_movable_pages(struct list_head *l)
 			continue;
 		}
 		list_del(&folio->lru);
-		if (unlikely(page_has_movable_ops(&folio->page))) {
-			putback_movable_ops_page(&folio->page);
+		if (unlikely(page_has_movable_ops(folio_page(folio, 0)))) {
+			putback_movable_ops_page(folio_page(folio, 0));
 		} else {
 			node_stat_mod_folio(folio, NR_ISOLATED_ANON +
 					folio_is_file_lru(folio), -folio_nr_pages(folio));

Is stupid. These things won't be folios in the future, so we actually *want to keep* using
&folio->page here as a reminder that this really must be reworked entirely differently.

Which makes this rather hard to review and makes me wonder whether core maintainers should
actually drive such a cleanup.

Unless Willy explicitly asked you to do that work, of course.

-- 
Cheers,

David