Re: [PATCH] mm/migrate_device: pin large folios before splitting

[Alistair Popple]

On 2026-07-02 at 06:16 +1000, Zi Yan <ziy@xxxxxxxxxx> wrote...
> On 1 Jul 2026, at 16:06, David Hildenbrand (Arm) wrote:
> 
> > On 7/1/26 21:27, Andrew Morton wrote:
> >> On Wed, 01 Jul 2026 13:02:10 -0400 Zi Yan <ziy@xxxxxxxxxx> wrote:
> >>
> >>> LGTM. Like David said, the comments might not be needed. Thanks.
> >>
> >> I like the comments!  They may be uninteresting to those who are
> >> already familiar with these things, but they aren't the target audience.
> >>
> >> How are others to become familiar, if not by this?
> >
> > I mean, it's one of the basic rules: if you lookup a page in the page table, the
> > moment you drop the lock that might be invalid.
> >
> > If we were to document that everywhere... this is not really the secret sauce we
> > want to document everywhere.
> 
> In this particular case, split_folio() is used in migrate_vma_split_folio()
> and split_folio() wraps __split_huge_page_to_list_to_order(), which documents
> the requirement of elevated folio reference. One who wants to get familiar
> with kernel code can be expected to chase down to
> __split_huge_page_to_list_to_order() and find the requirement.
> 
> With LLMs, it is probably as easy as asking “why is folio_get() needed here?”.

The interesting part of the comment isn't why the folio_get() is needed, it's
where the corresponding reference is dropped/returned. I've spent far too many
hours in this code trying to figure out why a page didn't migrate because of
a spurious refcount and it's not easy figuring out where the matching get/puts
occur.

So the comment could probably be condensed but I think it's valuable.

 - Alistair

> Best Regards,
> Yan, Zi