Re: [PATCH mm-unstable v4 5/5] mm/khugepaged: unify khugepaged and madv_collapse with collapse_single_pmd()

David Hildenbrand (Arm)
2026-04-01T07:06:00Z

On 3/31/26 23:49, Nico Pache wrote:
> On Tue, Mar 31, 2026 at 3:35 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> On Tue, 31 Mar 2026 22:00:58 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
>>
>>>
>>> Right.
>>>
>>> The original code used
>>>
>>> bool mmap_locked = true;
>>>
>>> If the fix get squashed, maybe we should revert to that handling to
>>> minimize the churn?
>>>
>>> (this is not in stable, right?)
>>
>> "mm/khugepaged: unify khugepaged and madv_collapse with
>> collapse_single_pmd(): is presently in mm-stable.
>>
>> Doing a big rebase&rework isn't the done thing, I believe. So queue it
>> afterwards, add the Fixes: and tolerate the minor runtime bisection
>> hole. It ends up looking like a later hotfix.
>>
>>
>> Below is what I added to mm-unstable. I added a note-to-self to check
>> in on Nico's question at
>> https://lore.kernel.org/all/CAA1CXcCYLGQBy9nT-MSTPVK=XgWWtD6Af-QiA_6pXtM_2pybPg@mail.gmail.com/T/#u
>>
>>
>> From: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
>> Subject: mm/khugepaged: fix issue with tracking lock
>> Date: Tue, 31 Mar 2026 13:11:18 +0100
>>
>> We are incorrectly treating lock_dropped to track both whether the lock is
>> currently held and whether or not the lock was ever dropped.
>>
>> Update this change to account for this.
>>
>> Link: https://lkml.kernel.org/r/7760c811-e100-4d40-9217-0813c28314be@lucifer.local
>> Fixes: 330f3758a3bc ("mm/khugepaged: unify khugepaged and madv_collapse with collapse_single_pmd()")
>> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
>> Reviewed-by: Lance Yang <lance.yang@linux.dev>
>> Reviewed-by: Nico Pache <npache@redhat.com>
>> ...
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>
>> mm/khugepaged.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> --- a/mm/khugepaged.c~mm-khugepaged-fix-issue-with-tracking-lock
>> +++ a/mm/khugepaged.c
>> @@ -2828,6 +2828,7 @@ int madvise_collapse(struct vm_area_stru
>> unsigned long hstart, hend, addr;
>> enum scan_result last_fail = SCAN_FAIL;
>> int thps = 0;
>> + bool mmap_unlocked = false;
>>
>> BUG_ON(vma->vm_start > start);
>> BUG_ON(vma->vm_end < end);
>> @@ -2850,10 +2851,11 @@ int madvise_collapse(struct vm_area_stru
>> for (addr = hstart; addr < hend; addr += HPAGE_PMD_SIZE) {
>> enum scan_result result = SCAN_FAIL;
>>
>> - if (*lock_dropped) {
>> + if (mmap_unlocked) {
>> cond_resched();
>> mmap_read_lock(mm);
>> - *lock_dropped = false;
>> + mmap_unlocked = false;
>> + *lock_dropped = true;
>> result = hugepage_vma_revalidate(mm, addr, false, &vma,
>> cc);
>> if (result != SCAN_SUCCEED) {
>> @@ -2864,7 +2866,7 @@ int madvise_collapse(struct vm_area_stru
>> hend = min(hend, vma->vm_end & HPAGE_PMD_MASK);
>> }
>>
>> - result = collapse_single_pmd(addr, vma, lock_dropped, cc);
>> + result = collapse_single_pmd(addr, vma, &mmap_unlocked, cc);
>>
>> switch (result) {
>> case SCAN_SUCCEED:
>> @@ -2893,8 +2895,10 @@ int madvise_collapse(struct vm_area_stru
>>
>> out_maybelock:
>> /* Caller expects us to hold mmap_lock on return */
>> - if (*lock_dropped)
>> + if (mmap_unlocked) {
>> + *lock_dropped = true;
>
> Hmm this was =false in David's example and = true here? Now i am also
> confused hahaha. It seems Lorenzo's code is correct. I think i
> responded to my own code changes, when I thought David was replying to
> Lorenzo's.

I think I messed up that in my posting when manually applying :)

So this here is correct.

--
Cheers,

David