On Thu, Feb 20, 2025 at 9:57 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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
