CVE-2024-53079: mm/thp: fix deferred split unqueue naming and locking

In the Linux kernel, the following vulnerability has been resolved:

mm/thp: fix deferred split unqueue naming and locking

Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing listdel 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.

Before fixing locking: rename misleading folioundolargermappable(), which does not undo largermappable, to foliounqueuedeferredsplit(), which is what it does. But that and its out-of-line callee are mm internals of very limited usability: add comment and WARNONONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARNONONCEs around safety checks (sparing callers the arcane conditionals in foliounqueuedeferredsplit()).

Just omit the foliounqueuedeferredsplit() from freeunreffolios(), all of whose callers now call it beforehand (and if any forget then badpage() will tell) - except for its caller putpageslist(), which itself no longer has any callers (and will be deleted separately).

Swapout: memcgroupswapout() has been resetting folio->memcgdata 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the splitqueuelock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. removemapping() has frozen refcount to 0 here, so no problem with calling foliounqueuedeferredsplit() before resetting memcgdata.

That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace.

Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment.

Memcg-v1 move (deprecated): memcgroupmoveaccount() has been changing folio->memcgdata without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so foliounqueuedeferredsplit() can only be used in a WARNONONCE to validate the fix, which must be done earlier: memcgroupmovechargepterange() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case.

The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false.

Backport to 6.11 should be straightforward. Earlier backports must take care that other deferredlist fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.