From: Lance Yang <lance.yang@linux.dev>
To: dev.jain@arm.com, ye.liu@linux.dev
Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org,
liuye@kylinos.cn, ziy@nvidia.com, baolin.wang@linux.alibaba.com,
liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com,
baohua@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/khugepaged: clear MMF_VM_HUGEPAGE on mm_slot_alloc() failure
Date: Fri, 1 May 2026 21:24:38 +0800 [thread overview]
Message-ID: <20260501132438.21298-1-lance.yang@linux.dev> (raw)
In-Reply-To: <aed7c1d5-2189-4ee2-b0f3-ce5a3e3c2118@arm.com>
On Fri, May 01, 2026 at 04:10:58PM +0530, Dev Jain wrote:
>
>
>On 01/05/26 1:27 pm, Ye Liu wrote:
>> From: Ye Liu <liuye@kylinos.cn>
>>
>> __khugepaged_enter() sets MMF_VM_HUGEPAGE before allocating the
>> corresponding mm_slot. If mm_slot_alloc() fails, the function
>> returns with the flag set but without inserting the mm into the
>> khugepaged tracking structures.
>>
>> This leaves the mm in an inconsistent state: it is marked as
>> registered (MMF_VM_HUGEPAGE set), but will never be scanned by
>> khugepaged. Future attempts to register the mm are skipped since
>> khugepaged_enter_vma() checks the flag and returns early.
>>
>> Fix this by clearing MMF_VM_HUGEPAGE when mm_slot_alloc() fails,
>> restoring the ability to retry registration later.
>>
>> Signed-off-by: Ye Liu <liuye@kylinos.cn>
>> ---
>> mm/khugepaged.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index 7d48d4fbd5f3..60ab7c1b61dd 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -559,8 +559,10 @@ void __khugepaged_enter(struct mm_struct *mm)
>> return;
>>
>> slot = mm_slot_alloc(mm_slot_cache);
>> - if (!slot)
>> + if (!slot) {
>> + mm_flags_clear(MMF_VM_HUGEPAGE, mm);
>> return;
>> + }
>
>You could just move the test_and_set() after this no?
Yep, that sounds better :)
Just one small thing: if we move the test_and_set(), after
mm_slot_alloc(), we need to free the slot when test_and_set() says that
the flag was already set. Otherwise the racing caller that loses would
leak the slot :)
Something like:
slot = mm_slot_alloc(mm_slot_cache);
if (!slot)
return;
if (unlikely(mm_flags_test_and_set(MMF_VM_HUGEPAGE, mm))) {
mm_slot_free(mm_slot_cache, slot);
return;
}
>So if slot allocation fails then MMF_VM_HUGEPAGE is never set.
>
>Fixes tag is probably required but not sure about Ccing stable.
Yes, Fixes sounds good. khugepaged collapse is best-effort though,
anyway :)
So I'm also not sure about Ccing stable.
>>
>> spin_lock(&khugepaged_mm_lock);
>> mm_slot_insert(mm_slots_hash, mm, slot);
Cheers, Lance
next prev parent reply other threads:[~2026-05-01 13:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 7:57 [PATCH] mm/khugepaged: clear MMF_VM_HUGEPAGE on mm_slot_alloc() failure Ye Liu
2026-05-01 10:40 ` Dev Jain
2026-05-01 13:24 ` Lance Yang [this message]
2026-05-05 4:17 ` Dev Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260501132438.21298-1-lance.yang@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuye@kylinos.cn \
--cc=ljs@kernel.org \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=ye.liu@linux.dev \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.