Re: [PATCH v3 10/18] mm: Allow non-hugetlb large folios to be batch processed

[Matthew Wilcox <willy@infradead.org>]

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.