From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) (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 BD0E036EA8B for ; Mon, 11 May 2026 03:11:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778469099; cv=none; b=R2auODnSMK+86wLg7ln2ycdse+O05lUmrVOH1qkcyOZd5LHjXb09Lpad21aipMIHzMBZ2c1dv3qxJRuAMVg6SL+B2pwUAk05JuiqS8ptmf1mJux4AhVZhAMA7CyHvt9grUNviRmprhOIzAn4OHbiDW1vzyaYK41HzgC8emiaQ/k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778469099; c=relaxed/simple; bh=lWz/tyUml7MJdxBvg9XiwLDiAfOOAoQkKQlJIbKE/Ok=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fm11tserFxbUhW6BeejmWS75ApiLTWaOGXQMaUuO96McACNsA5x2fGPNqw0LBtBhVwgYh9NUYzaCxrDw/si14C+ZUUrkSpNTOHF5yv1DZq1BswhRAf7dgK0XNZb7LjrLvfvjDtGL3lrjp5PKZ8wgHyGH+Ea3bql/vEWZ4r+Ohv4= 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=tw0aVY8a; arc=none smtp.client-ip=95.215.58.178 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="tw0aVY8a" Message-ID: <49787989-f05f-4e2c-bbad-bd8fa0e19dff@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778469094; 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=cL0FELGoVYHYTfhfL2RHbUuOhJzysi3xHVnV5drpBKA=; b=tw0aVY8ay56GlUCDSCSYyOfeV/6Vr4TLp7y6hN9kIzYmg6dA3V/AjJnAKwjAXaHRciTwhp iiOup3nQKXgLjTE9CITs1ZorXI/i5bfzIuBJWNa3SSPT0VJfwJjcL4VULO1Nde1Ac1ykrP j6QidKjpP7t2u7k5sPCL+kYb8LLuhhE= Date: Mon, 11 May 2026 11:11:16 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v3] mm/khugepaged: fix inconsistent MMF_VM_HUGEPAGE flag due to allocation failure order To: Ye Liu Cc: Ye Liu , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Xin Hao , Lorenzo Stoakes , David Hildenbrand , Ryan Roberts , Dev Jain , Barry Song , Andrew Morton , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260511025408.54035-1-ye.liu@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20260511025408.54035-1-ye.liu@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/5/11 10:54, 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, leaving the mm in an inconsistent > state where future registration attempts are skipped. > > Fix this by reordering: allocate the mm_slot first, then check and > set the flag. If the flag is already set, free the allocated slot > and return. This ensures the flag is only set when the mm is > successfully registered in the khugepaged tracking structures. > > Fixes: 16618670276a ("mm: khugepaged: avoid pointless allocation for "struct mm_slot"") > Suggested-by: David Hildenbrand > Signed-off-by: Ye Liu > --- LGTM, thanks. Reviewed-by: Lance Yang