On Sat, Mar 09, 2024 at 12:33:44PM +0000, Ryan Roberts wrote:
> >> diff --git a/mm/swap.c b/mm/swap.c
> >> index 6b697d33fa5b..7b1d3144391b 100644
> >> --- a/mm/swap.c
> >> +++ b/mm/swap.c
> >> @@ -1012,6 +1012,8 @@ void folios_put_refs(struct folio_batch *folios, unsigned int *refs)
> >> free_huge_folio(folio);
> >> continue;
> >> }
> >> + if (folio_test_large(folio) && folio_test_large_rmappable(folio))
> >> + folio_undo_large_rmappable(folio);
> >>
> >> __page_cache_release(folio, &lruvec, &flags);
> >>
> >
> > I agree this is likely to re-hide the problems. But I haven't actually tested it
> > on it's own without the other fixes. I'll do some more testing with your latest
> > patch and if that doesn't lead anywhere, I'll test with this on its own to check
> > that I can no longer reproduce the crashes. If it hides them, I think this is
> > the best short-term solution we have right now.
>
> I've tested this workaround on immediately on top of commit f77171d241e3 ("mm:
> allow non-hugetlb large folios to be batch processed") and can't reproduce any
> problem. I've run the test 32 times. Without the workaround, the biggest number
> of test repeats I've managed before seeing a problem is ~5. So I'm confident
> this will be sufficient as a short-term solution.
Let's make this the 6.9 solution. Having looked at a lot of bits of
the page freeing path, I'll do some significant rearranging for 6.10,
but this is tested and time is short. Proper patch shortly.
