Re: [PATCH v12 mm-new 07/15] khugepaged: generalize collapse_huge_page for mTHP collapse
From: Dev Jain <dev.jain@arm.com>
Date: 2025-11-07 03:09:21
Also in:
linux-doc, linux-mm, lkml
From: Dev Jain <dev.jain@arm.com>
Date: 2025-11-07 03:09:21
Also in:
linux-doc, linux-mm, lkml
----------[snip]------------quoted
+ + spin_lock(pmd_ptl);We're duplicating this in both branches, why not do outside if/else?quoted
+ WARN_ON_ONCE(!pmd_none(*pmd));Hmm so the PMD entry will still always be empty on mTHP collapse? Surely we could be collapsing more than one mTHP into an existing PTE table no? I may be missing something here/confused :)
After this code path isolates the PTE table, we don't want any other code path doing "Hey, I see an empty PMD, let's install a PTE table here". One of the reasons why all the heavy locking is required here. Also, I want to ask a question about WARN vs BUG_ON: suppose that the race I described above occurs. After khugepaged isolates the PTE table, someone faults in a PTE table there, and eventually writes data in the underlying folios. Then the buggy khugepaged nukes out that table and installs a new one, installing an mTHP folio which had old data. How do we decide whether such a condition is worthy of a BUG_ON (leading to system crash) vs letting this pass with WARN?
------------[snip]----------