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

[Barry Song <21cnbao@gmail.com>]

On Thu, Feb 20, 2025 at 9:57 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Feb 20, 2025 at 09:37:50AM +1300, Barry Song wrote:
> > > How complex would that be? Is it a matter of adding
> > > folio_maybe_dma_pinned() checks, doing folio_move_anon_rmap() and
> > > folio->index = linear_page_index like in move_present_pte() or
> > > something more?
> >
> > My main concern is still with large folios that require a split_folio()
> > during move_pages(), as the entire folio shares the same index and
> > anon_vma. However, userfaultfd_move() moves pages individually,
> > making a split necessary.
> >
> > However, in split_huge_page_to_list_to_order(), there is a:
> >
> >         if (folio_test_writeback(folio))
> >                 return -EBUSY;
> >
> > This is likely true for swapcache, right?
>
> I don't see why?  When they get moved to the swap cache, yes, they're
> immediately written back, but after being swapped back in, they stay in
> the swap cache, so they don't have to be moved back to the swap cache.
> Right?

I don’t quite understand your question. The issue we’re discussing is
that the folio is in swapcache. Right now, we’re encountering a kernel
crash because we haven’t fixed the folio’s index. If we want to address
that, we need to perform a split_folio() for mTHP. Since we’re already
dealing with swapcache, we’re likely in a situation where we’re doing
writeback (pageout), considering Android uses sync zram. So, if
swapcache is true, writeback is probably true as well.

The race occurs after we call add_to_swap(), try_to_unmap() and
before we complete the writeback - page. (Swapcache will be cleared
for the sync device once the writeback is finished.)

Thanks
Barry