On Sun, 27 Oct 2024, Zi Yan wrote:
> On 27 Oct 2024, at 15:59, Hugh Dickins wrote:
>
> > Recent changes are putting more pressure on THP deferred split queues:
> > under load revealing long-standing races, causing list_del corruptions,
> > "Bad page state"s and worse (I keep BUGs in both of those, so usually
> > don't get to see how badly they end up without). The relevant recent
> > changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin,
> > improved swap allocation, and underused THP splitting.
> >
> > The new unlocked list_del_init() in deferred_split_scan() is buggy.
> > I gave bad advice, it looks plausible since that's a local on-stack
> > list, but the fact is that it can race with a third party freeing or
> > migrating the preceding folio (properly unqueueing it with refcount 0
> > while holding split_queue_lock), thereby corrupting the list linkage.
> >
> > The obvious answer would be to take split_queue_lock there: but it has
> > a long history of contention, so I'm reluctant to add to that. Instead,
> > make sure that there is always one safe (raised refcount) folio before,
> > by delaying its folio_put(). (And of course I was wrong to suggest
> > updating split_queue_len without the lock: leave that until the splice.)
> >
> > And remove two over-eager partially_mapped checks, restoring those tests
> > to how they were before: if uncharge_folio() or free_tail_page_prepare()
> > finds _deferred_list non-empty, it's in trouble whether or not that folio
> > is partially_mapped (and the flag was already cleared in the latter case).
> >
> > Fixes: dafff3f4c850 ("mm: split underused THPs")
> > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>
> > Acked-by: Usama Arif <usamaarif642@xxxxxxxxx>
> > Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>
> > Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> > ---
> > Based on 6.12-rc4
> > v2: added ack and reviewed-bys
>
> Acked-by: Zi Yan <ziy@xxxxxxxxxx>
Thank you: but I owe you and Andrew and everyone else an apology.
Those 1/2 and 2/2, which have gone in to Linus's tree this morning
(thank you all), have still left a once-a-week list_del corruption on
the deferred split queue: which I've been agonizing over then giving up
on repeatedly for three weeks now (last weekend's seemed to get fixed by
applying a missed microcode update; but then another crash this Friday).
Sorry if the timing makes it look as if I'm trying to game the system
in some way, but it was only yesterday evening that at last I understood
the reason for (I hope the last of) these deferred split queue corruptions;
and the fix turns out to be to this patch. Perhaps if I'd worked out why
sooner, I'd have just switched to proper spinlocking as you asked; but now
that I do understand, I still prefer to continue this much more tested way.
My ability to reproduce these crashes seems to be one or two orders of
magnitude weaker than it used to be (generally a good thing I suppose: but
frustrating when I want to test), and there's no way I can satisfy myself
that the crashes are completely eliminated in a single week.
But I have been successful in adding temporary debug code, to check that
the preceding "safe" folio on the local list has non-0 refcount: that
check fails much sooner than reaching corruption, and I've run it often
enough now to confirm that the fix does fix that.
Fix patch follows... as you'll see, it's very obvious *in retrospect*.
Hugh
