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

[Matthew Wilcox <willy@infradead.org>]

On Fri, Mar 08, 2024 at 03:11:35PM +0000, Matthew Wilcox wrote:
> Actually, I have a clue!  The third and fourth word have the same value.
> That's indicative of an empty list_head.  And if this were LRU, that would
> be the second and third word.  And the PFN is congruent to 2 modulo 4.
> So this is the second tail page, and that's an empty deferred_list.
> So how do we init a list_head after a folio gets freed?

We should probably add this patch anyway, because why wouldn't we want
to check this.  Maybe it'll catch your offender?

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 025ad1a7df7b..fc9c7ca24c4c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1007,9 +1007,12 @@ static int free_tail_page_prepare(struct page *head_page, struct page *page)
 		break;
 	case 2:
 		/*
-		 * the second tail page: ->mapping is
-		 * deferred_list.next -- ignore value.
+		 * the second tail page: ->mapping is deferred_list.next
 		 */
+		if (unlikely(!list_empty(&folio->_deferred_list))) {
+			bad_page(page, "still on deferred list");
+			goto out;
+		}
 		break;
 	default:
 		if (page->mapping != TAIL_MAPPING) {

(thinking about it, this may not be right for all tail pages; will Slab
stumble over this?  It doesn't seem to stumble on _entire_mapcount, but
then we always initialise _entire_mapcount for all compound pages
and we don't initialise _deferred_list for slab ... gah)