From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BCB48214813 for ; Tue, 5 May 2026 04:17:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777954673; cv=none; b=uoHRXzd+iYBSFnP6pLz04hXKcdTMHvdUAsc4t0nWISbmE6JF82KvVBu49Spa3j/nuv27qMut25QFtqROrLY/F3UFE64YC3GMIxAozgubXCcII1EzTbrdH06vkHppquImZRrNfT2PBRmv3HUpe7S3REsKLRoplax7ABmcK/QahBU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777954673; c=relaxed/simple; bh=3niOScSs9vDuIoOXeNfLH2FfR3PwvJa8d1SMHBMmudg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bOOai5gEWYshqzvmz9ZUxuL8G/+Pk1okhPb27ugC4Lkfi2CDdWnUs0trqo2Bd0PD7mbRQMRVLxt++BULoBqs0EoPHovQV5tuObE7bHdakobihM32Wz5EdxC6Xx9G0s7UV1iluPc4guXYilh5gG59Nq8Xs1Tbu52ZqhCs3DWyx/c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=TaOjExPQ; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="TaOjExPQ" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 47A9B26AC; Mon, 4 May 2026 21:17:44 -0700 (PDT) Received: from [10.164.148.38] (unknown [10.164.148.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7ADDC3F763; Mon, 4 May 2026 21:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1777954669; bh=3niOScSs9vDuIoOXeNfLH2FfR3PwvJa8d1SMHBMmudg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TaOjExPQK1qTV0xeD1xjGLwLWEehBwxndVA0mwb4KWqiXfbYVVjWMVMZ6k/orqpwY 0nw6Wz73l1pPh2Kzpibwigm/zPgyWpTmoS84+/2Qnnk+XTMKPOUA0UvwxLNRQe+6/1 lArMX9rEBL02CHDipEGKrxjkm4EGPOJ0eY1LINAU= Message-ID: Date: Tue, 5 May 2026 09:47:24 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/khugepaged: clear MMF_VM_HUGEPAGE on mm_slot_alloc() failure To: Lance Yang , 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, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260501132438.21298-1-lance.yang@linux.dev> Content-Language: en-US From: Dev Jain In-Reply-To: <20260501132438.21298-1-lance.yang@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/05/26 6:54 pm, Lance Yang wrote: > > 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 >>> >>> __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 >>> --- >>> 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; > } My bad, I missed the fact that test-and-set may also fail. So I think Ye's patch is also fine. > >> 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