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

Nico Pache
2026-03-31T21:50:26Z

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:
>
> > > out_maybelock:
> > > /* Caller expects us to hold mmap_lock on return */
> > > if (mmap_unlocked) {
> > > *lock_dropped = true;
> > > mmap_read_lock(mm);
> > > }
> > >
> >
> > 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 we are all good with Lorenzo's changes.

Sorry for the confusion

-- Nico

> mmap_read_lock(mm);
> + }
> out_nolock:
> mmap_assert_locked(mm);
> mmdrop(mm);
> _
>