Thread (91 messages) 91 messages, 11 authors, 2025-11-26

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

----------[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]----------
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help