From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-150.mta1.migadu.com [95.215.58.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8670A3AD50D for ; Thu, 13 Aug 2026 09:50:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.150 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786614629; cv=none; b=jE++nG/45edzx9zbI32iKMEGuAMWGyjMF3DAlP8yqicWhk8i7mI5q19MqZJL2Xu9ym31sZV4xJZ9uzJ/OpzmFiAdlt85yRp5nQGKfrUl2RirL8H4NqYIJXhCoJcez3VpJ94X0DKQUkLvrq0RWcUC4kTrPzD9hCTSAYtqwHDSGp4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786614629; c=relaxed/simple; bh=vYCSz1ZEZdbvEGeeo3EZ9moH+qt+41PQR7+RZ+seBJ8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SjX2YAnY0b7NKH4c1F/aKa0zUjZ7Fj2PryAqjQx+rh5bjBeV0RcBg1INU3YEQDvTpijxpaBcx9YjZbHR8ZqEam/2+BKua1MUjRH0Uw9NwIYPJuxlDcbK9/OJyy0tT9LUWxy2YNBOt+f++u4KctR0u0x3R+5T1h8E7ETC3tLhFDQ= 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=bsiX3+Zw; arc=none smtp.client-ip=95.215.58.150 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="bsiX3+Zw" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=vYCSz1ZEZdbvEGeeo3EZ9moH+qt+41PQR7+RZ+seBJ8=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786614625; v=1; x=1787219425; b=bsiX3+ZwgOlbl6aQxP7jpWAnBYFGJaEtNMpGPkhQPLj2Jh4f96qOK13wIL+OYxD84gnUmHJY 2BIVJx9bXcknbIU8oJrniCqImVL94tAmh+ju+5iq/71OOVZmnLhfbIhqIhHaLSaNVvWYaH9GY7Y k4XULHzyplCggnZqdXe4MHNE= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [192.168.111.29] (223.70.159.239) by smtp.migadu.com with ESMTPS id 15f9e16fe78d2e8f; Thu, 13 Aug 2026 09:50:25 +0000 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Thu, 13 Aug 2026 17:50:21 +0800 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/oom_kill: fix stale comment in constrained_alloc() To: Michal Hocko Cc: Andrew Morton , Ye Liu , David Rientjes , Shakeel Butt , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260813030654.320269-1-ye.liu@linux.dev> Content-Language: en-US From: Ye Liu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 在 2026/8/13 16:43, Michal Hocko 写道: > On Thu 13-08-26 11:06:54, Ye Liu wrote: >> From: Ye Liu >> >> The comment above the __GFP_THISNODE check in constrained_alloc() >> is stale and inaccurate: it references __GFP_NOFAIL (which is not >> checked here), claims the OOM killer does "random task kill" (it >> uses badness scores), and mentions CONSTRAINT_THISNODE (which was >> never added to the enum). Replace it with a description that >> matches the actual code behavior. > > The comment is indeed confusing and stale. Your update unfortunatelly as > well. This code is simply unreachable because we never trigger global > OOM with __GFP_THISNODE (see __alloc_pages_may_oom) and for memcg OOM > __GFP_THISNODE is immaterial. > I directly deleted the invalid code and sent v2. >> Signed-off-by: Ye Liu >> --- >> mm/oom_kill.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/mm/oom_kill.c b/mm/oom_kill.c >> index 5f372f6e26fa..4b5c70aaece4 100644 >> --- a/mm/oom_kill.c >> +++ b/mm/oom_kill.c >> @@ -268,9 +268,9 @@ static enum oom_constraint constrained_alloc(struct oom_control *oc) >> if (!oc->zonelist) >> return CONSTRAINT_NONE; >> /* >> - * Reach here only when __GFP_NOFAIL is used. So, we should avoid >> - * to kill current.We have to random task kill in this case. >> - * Hopefully, CONSTRAINT_THISNODE...but no way to handle it, now. >> + * __GFP_THISNODE means the allocation is restricted to a single node. >> + * There is no dedicated constraint type for this case, so return >> + * CONSTRAINT_NONE and let the normal OOM handling proceed. >> */ >> if (oc->gfp_mask & __GFP_THISNODE) >> return CONSTRAINT_NONE; >> -- >> 2.25.1 > -- Thanks, Ye Liu