From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 711D539B95C for ; Wed, 6 May 2026 10:52:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778064735; cv=none; b=DhBpa88EOhaXh5Pvu4eG4k22yZFJHa9586+XCtSRJD1hjzO1ZHYCtpbdZouVYG8bYHGw6QeLPaItspuFtnNm9qdvnTrfAyhz7yxTRRvj1OPGPN0VuWvHZX9SySfEenfbMKqAXglgN6kCP6lxb6CbMHdvMRzdkYxv+XgpDdGuPpU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778064735; c=relaxed/simple; bh=uAsxdIoQw8O0y1K8f91Wll/DTnmoQWZWjjd94wduBjo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=b3lmZYKmm9bJUqDBJR9up80uw8JoiW8drODP5JSSCKNURDpqKWz7n1Z1IQ4VWxEDfEfpttPai9D1InRNDCG7xXMS5nM8BuAqRfPAiWlbORGmZphHJK41qz7ScyaZlpUS1S12itK0Gu00RynF6S0f/7++vkQZYMmtm2ND6ePdWpo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=kRr/BDzP; arc=none smtp.client-ip=95.215.58.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="kRr/BDzP" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778064731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zMpt19AKtKXEf6HWZe6U2H7Rk78vElmD03to1iCaQW0=; b=kRr/BDzPfvHOut3Z5oRlb3TEmEcS+FurdMrniRy8OxU1SGMGBeUkPGaSEra56z5HxgJUX6 F7FR0vRd0mJzuTkApRYf4c2M+51HpXfFqFUomT/CpNHdi1qWExhIVEr+/Mo2QIp+KZLFS/ FFU/nS6HN5MXx4+fLxmrleTdauY2C7k= From: Lance Yang To: dev.jain@arm.com Cc: ye.liu@linux.dev, akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, xhao@linux.alibaba.com, 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, akpm@linux-foudation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/khugepaged: clear MMF_VM_HUGEPAGE on mm_slot_alloc() failure Date: Wed, 6 May 2026 18:51:50 +0800 Message-Id: <20260506105150.21504-1-lance.yang@linux.dev> In-Reply-To: <3fb8c00d-d60d-4fec-81b1-e7633384a52d@arm.com> References: <3fb8c00d-d60d-4fec-81b1-e7633384a52d@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Wed, May 06, 2026 at 12:16:35PM +0530, Dev Jain wrote: > > >On 06/05/26 6:51 am, 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. >> >> Fixes: 16618670276a ("mm: khugepaged: avoid pointless allocation for struct mm_slot") >> Signed-off-by: Ye Liu >> --- >> Changes since v1: >> - Add Fixes tag as suggested by Dev Jain and Lance Yang >> >> 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; >> + } > >Note that, a racing khugepaged_enter_vma() may back off >when it sees that MMF_VM_HUGEPAGE is set, but then the above >clears the flag after slot alloc failure. So we end up not >registering the mm with khugepaged. But I am sure no one >cares, we are in much big trouble if slot alloc is failing. Right. A racing khugepaged_enter_vma() can see MMF_VM_HUGEPAGE is set and return, then !slot clears it again. If there is no later khugepaged_enter_vma(), the mm still wouldn't get registered :) >Although one could argue the same about this patch, I will >still say it is important to fix "flag is set but not registered >with khugepaged" because that just feels wrong. +1 that is still better then keeping MMF_VM_HUGEPAGE set forever: any later attempt can retry and install the mm_slot :) Cheers, Lance