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

[David Hildenbrand (Arm)]

On 3/31/26 23:49, Nico Pache wrote:
> On Tue, Mar 31, 2026 at 3:35 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> On Tue, 31 Mar 2026 22:00:58 +0200 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/T/#u
>>
>>
>> From: "Lorenzo Stoakes (Oracle)" <ljs@xxxxxxxxxx>
>> 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@xxxxxxxxxx>
>> Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>
>> Reviewed-by: Nico Pache <npache@xxxxxxxxxx>
>> ...
>> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> ---
>>
>>  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