Re: [PATCH RFC 3/3] mm: remove folio_test_anon(folio)==false path in __folio_add_anon_rmap()

[David Hildenbrand]

On 13.06.24 10:46, Barry Song wrote:
> On Thu, Jun 13, 2024 at 12:08 PM Barry Song <21cnbao@xxxxxxxxx> wrote:
> > From: Barry Song <v-songbaohua@xxxxxxxx>
> >
> > The folio_test_anon(folio)==false case within do_swap_page() has been
> > relocated to folio_add_new_anon_rmap(). Additionally, two other callers
> > consistently pass anonymous folios.
> >
> > stack 1:
> > remove_migration_pmd
> >     -> folio_add_anon_rmap_pmd
> >       -> __folio_add_anon_rmap
> >
> > stack 2:
> > __split_huge_pmd_locked
> >     -> folio_add_anon_rmap_ptes
> >        -> __folio_add_anon_rmap
> >
> > __folio_add_anon_rmap() only needs to handle the cases
> > folio_test_anon(folio)==true now.
>
> My team reported a case where swapoff() is calling
> folio_add_anon_rmap_pte *not* folio_add_anon_rmap_ptes
> with one new anon  (!folio_test_anon(folio)).
>
> I will double check all folio_add_anon_rmap_pte() cases.

Right, swapoff() path is a bit special (e.g., we don't do any kind of 
batching on the swapoff() path).

But we should never get a new large anon folio there, or could that now 
happen?

--
Cheers,

David / dhildenb