Re: [PATCH v5 09/17] mm/huge_memory: rename remap_page() to remap_anon_folio()

[Kairui Song]

On Fri, Sep 18, 2026 at 10:46:55PM +0100, David Hildenbrand (Arm) wrote:
> On 9/14/26 19:14, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@xxxxxxxxxxx>
> > 
> > remap_page() now only has one caller, __folio_freeze_split_anon(),
> > and is only ever called for anon folios: unmap_folio() currently
> > leaves file folios unmapped after the split, so they need no
> > remapping.
> > 
> > Rename it to remap_anon_folio() to make that explicit, and add a
> > VM_WARN_ON_FOLIO() documenting it.
> > 
> > Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>
> > Reviewed-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
> > Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> > ---
> >  mm/huge_memory.c | 17 ++++++++++++-----
> >  1 file changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 1749905ade6a..77bf68c9b9af 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -3552,7 +3552,7 @@ static void unmap_folio(struct folio *folio)
> >  	/*
> >  	 * Anon pages need migration entries to preserve them, but file
> >  	 * pages can simply be left unmapped, then faulted back on demand.
> > -	 * If that is ever changed (perhaps for mlock), update remap_page().
> > +	 * If that is ever changed (perhaps for mlock), update remap_anon_folio().
> 
> See my comment below, delete that comment about "what if X" entirely. Also, we
> wouldn't want to update remap_anon_folio().

Sure, it was added due to some previous reviews, but things are cleaner
now with the renaming so just remove it is indeed better.

...

> 
> Add remap_anon_folio for file folios? Just delete this entire code comment.
> Whoever wants to implement that can look into the pieces that are actually needed.
> 
> 
> With the comments sorted

Thanks!