On 3/7/2024 4:56 PM, wrote:
I just want to make sure I've understood correctly: CPU1's folio_put()
is not the last reference, and it keeps iterating through the local
list. Then CPU2 does the final folio_put() which causes list_del_init()
to modify the local list concurrently with CPU1's iteration, so CPU1
probably goes into the weeds?
My understanding is this can not corrupt the folio->deferred_list as
this folio was iterated already.
But I did see other strange thing:
[ 76.269942] page: refcount:0 mapcount:1 mapping:0000000000000000
index:0xffffbd0a0 pfn:0x2554a0
[ 76.270483] note: kcompactd0[62] exited with preempt_count 1
[ 76.271344] head: order:0 entire_mapcount:1 nr_pages_mapped:0 pincount:0
This large folio has order 0? Maybe folio->_flags_1 was screwed?
In free_unref_folios(), there is code like following:
if (order > 0 && folio_test_large_rmappable(folio))
folio_undo_large_rmappable(folio);
But with destroy_large_folio():
if (folio_test_large_rmappable(folio))
folio_undo_large_rmappable(folio);
Can it connect to the folio has zero refcount still in deferred list
with Matthew's patch?
Looks like folio order was cleared unexpected somewhere.
Regards
Yin, Fengwei
