From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A311C4338F for ; Mon, 2 Aug 2021 06:43:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 155FB61042 for ; Mon, 2 Aug 2021 06:43:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 155FB61042 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A77176B0033; Mon, 2 Aug 2021 02:43:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A272B6B0036; Mon, 2 Aug 2021 02:43:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F10D8D0001; Mon, 2 Aug 2021 02:43:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) by kanga.kvack.org (Postfix) with ESMTP id 717FE6B0033 for ; Mon, 2 Aug 2021 02:43:30 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2B1C58249980 for ; Mon, 2 Aug 2021 06:43:30 +0000 (UTC) X-FDA: 78429199380.31.CF4CF84 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id AB0F5200171C for ; Mon, 2 Aug 2021 06:43:29 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id EC3E121FC1; Mon, 2 Aug 2021 06:43:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1627886595; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kKU12K2fBZbHqr4t5nmrbX+sTG0uq/OYc4mzSKOcY+E=; b=ItZF/JTnMqza/U+as0Qgt/GrVy+8VM1qC0l9HUtskjjbfn77AOblkta5K0FTgJiLUeh9Mw DdqJFqHwU0JniuUu0LJhAsf07/XaWh1xfVTZ5mjIwN2OdEBMxIz4qBTcOBnmJJnObwnS8c 8XQkm1MjNBQBx8WecYSxILo3+yYTO6s= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 46A27A3B83; Mon, 2 Aug 2021 06:43:15 +0000 (UTC) Date: Mon, 2 Aug 2021 08:43:13 +0200 From: Michal Hocko To: Miaohe Lin Cc: Roman Gushchin , hannes@cmpxchg.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, shakeelb@google.com, willy@infradead.org, alexs@kernel.org, richard.weiyang@gmail.com, songmuchun@bytedance.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH 4/5] mm, memcg: avoid possible NULL pointer dereferencing in mem_cgroup_init() Message-ID: References: <20210729125755.16871-1-linmiaohe@huawei.com> <20210729125755.16871-5-linmiaohe@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="ItZF/JTn"; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AB0F5200171C X-Stat-Signature: 4xzcc9cuj4s1wf43icnrzot86kkdw43e X-HE-Tag: 1627886609-696168 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat 31-07-21 10:05:51, Miaohe Lin wrote: > On 2021/7/30 14:44, Michal Hocko wrote: > > On Thu 29-07-21 20:12:43, Roman Gushchin wrote: > >> On Thu, Jul 29, 2021 at 08:57:54PM +0800, Miaohe Lin wrote: > >>> rtpn might be NULL in very rare case. We have better to check it before > >>> dereferencing it. Since memcg can live with NULL rb_tree_per_node in > >>> soft_limit_tree, warn this case and continue. > >>> > >>> Signed-off-by: Miaohe Lin > >>> --- > >>> mm/memcontrol.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c > >>> index 5b4592d1e0f2..70a32174e7c4 100644 > >>> --- a/mm/memcontrol.c > >>> +++ b/mm/memcontrol.c > >>> @@ -7109,6 +7109,8 @@ static int __init mem_cgroup_init(void) > >>> rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL, > >>> node_online(node) ? node : NUMA_NO_NODE); > >>> > >>> + if (WARN_ON_ONCE(!rtpn)) > >>> + continue; > >> > >> I also really doubt that it makes any sense to continue in this case. > >> If this allocations fails (at the very beginning of the system's life, it's an __init function), > >> something is terribly wrong and panic'ing on a NULL-pointer dereference sounds like > >> a perfect choice. > > > > Moreover this is 24B allocation during early boot. Kernel will OOM and > > panic when not being able to find any victim. I do not think we need to > > Agree with you. But IMO it may not be a good idea to leave the rtpn without NULL check. We should defend > it though it could hardly happen. But I'm not insist on this check. I will drop this patch if you insist. It is not that I would insist. I just do not see any point in the code churn. This check is not going to ever trigger and there is nothing you can do to recover anyway so crashing the kernel is likely the only choice left. -- Michal Hocko SUSE Labs