Re: [PATCH RFC] mm: Fix kernel BUG when userfaultfd_move encounters swapcache

[Barry Song]

On Fri, Feb 21, 2025 at 12:32 PM Peter Xu <peterx@xxxxxxxxxx> wrote:
>
> On Thu, Feb 20, 2025 at 10:21:01PM +1300, Barry Song wrote:
> > 2. src_anon_vma and its lock – swapcache doesn’t require it（folio is not mapped）
>
> Could you help explain what guarantees the rmap walk not happen on a
> swapcache page?
>
> I'm not familiar with this path, though at least I see damon can start a
> rmap walk on PageAnon almost with no locking..  some explanations would be
> appreciated.

I am observing the following in folio_referenced(), which the anon_vma lock
was originally intended to protect.

        if (!pra.mapcount)
                return 0;

I assume all other rmap walks should do the same?

int folio_referenced(struct folio *folio, int is_locked,
                     struct mem_cgroup *memcg, unsigned long *vm_flags)
{

        bool we_locked = false;
        struct folio_referenced_arg pra = {
                .mapcount = folio_mapcount(folio),
                .memcg = memcg,
        };

        struct rmap_walk_control rwc = {
                .rmap_one = folio_referenced_one,
                .arg = (void *)&pra,
                .anon_lock = folio_lock_anon_vma_read,
                .try_lock = true,
                .invalid_vma = invalid_folio_referenced_vma,
        };

        *vm_flags = 0;
        if (!pra.mapcount)
                return 0;
        ...
}

By the way, since the folio has been under reclamation in this case and
isn't in the lru, this should also prevent the rmap walk, right?

>
> --
> Peter Xu
>

Thanks
Barry