From: Miaohe Lin <linmiaohe@huawei.com> To: Roman Gushchin <guro@fb.com> Cc: <hannes@cmpxchg.org>, <mhocko@kernel.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() Date: Fri, 30 Jul 2021 14:29:57 +0800 [thread overview] Message-ID: <2a9353e0-9ece-d8d5-1387-202b01b0fdad@huawei.com> (raw) In-Reply-To: <YQNuK+jN7pZLJTvT@carbon.lan> On 2021/7/30 11:12, 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 <linmiaohe@huawei.com> >> --- >> 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. > > Is this a real world problem? Do I miss something? No, this is a theoretical bug, a very race case but not impossible IMO. Since we can't live with NULL rb_tree_per_node in soft_limit_tree, I thinks simply continue or break here without panic is also acceptable. Or is it more proper to choose panic here? Thanks. > . >
WARNING: multiple messages have this Message-ID (diff)
From: Miaohe Lin <linmiaohe@huawei.com> To: Roman Gushchin <guro@fb.com> Cc: hannes@cmpxchg.org, mhocko@kernel.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() Date: Fri, 30 Jul 2021 14:29:57 +0800 [thread overview] Message-ID: <2a9353e0-9ece-d8d5-1387-202b01b0fdad@huawei.com> (raw) In-Reply-To: <YQNuK+jN7pZLJTvT@carbon.lan> On 2021/7/30 11:12, 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 <linmiaohe@huawei.com> >> --- >> 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. > > Is this a real world problem? Do I miss something? No, this is a theoretical bug, a very race case but not impossible IMO. Since we can't live with NULL rb_tree_per_node in soft_limit_tree, I thinks simply continue or break here without panic is also acceptable. Or is it more proper to choose panic here? Thanks. > . >
next prev parent reply other threads:[~2021-07-30 6:30 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-29 12:57 [PATCH 0/5] Cleanups and fixup for memcontrol Miaohe Lin 2021-07-29 12:57 ` Miaohe Lin 2021-07-29 12:57 ` [PATCH 1/5] mm, memcg: remove unused functions Miaohe Lin 2021-07-29 12:57 ` Miaohe Lin 2021-07-29 14:07 ` Shakeel Butt 2021-07-29 14:07 ` Shakeel Butt 2021-07-30 2:39 ` Muchun Song 2021-07-30 2:39 ` Muchun Song 2021-07-30 2:57 ` Roman Gushchin 2021-07-30 2:57 ` Roman Gushchin 2021-07-30 6:45 ` Michal Hocko 2021-07-30 6:45 ` Michal Hocko 2021-07-29 12:57 ` [PATCH 2/5] mm, memcg: narrow the scope of percpu_charge_mutex Miaohe Lin 2021-07-29 12:57 ` Miaohe Lin 2021-07-30 2:42 ` Muchun Song 2021-07-30 2:42 ` Muchun Song 2021-07-30 3:06 ` Roman Gushchin 2021-07-30 3:06 ` Roman Gushchin 2021-07-30 6:50 ` Michal Hocko 2021-07-30 6:50 ` Michal Hocko 2021-07-31 2:29 ` Miaohe Lin 2021-07-31 2:29 ` Miaohe Lin 2021-08-02 6:49 ` Michal Hocko 2021-08-02 6:49 ` Michal Hocko 2021-08-02 9:54 ` Miaohe Lin 2021-08-02 9:54 ` Miaohe Lin 2021-08-03 3:40 ` Roman Gushchin 2021-08-03 3:40 ` Roman Gushchin 2021-08-03 6:29 ` Miaohe Lin 2021-08-03 6:29 ` Miaohe Lin 2021-08-03 7:11 ` Michal Hocko 2021-08-03 7:11 ` Michal Hocko 2021-08-03 7:13 ` Roman Gushchin 2021-08-03 7:13 ` Roman Gushchin 2021-08-03 7:27 ` Michal Hocko 2021-08-03 7:27 ` Michal Hocko 2021-08-03 9:33 ` Muchun Song 2021-08-03 9:33 ` Muchun Song 2021-08-03 10:50 ` Miaohe Lin 2021-08-03 10:50 ` Miaohe Lin 2021-08-03 14:15 ` Johannes Weiner 2021-08-03 14:15 ` Johannes Weiner 2021-08-04 8:20 ` Michal Hocko 2021-08-04 8:20 ` Michal Hocko 2021-08-05 1:44 ` Miaohe Lin 2021-08-05 1:44 ` Miaohe Lin 2021-07-30 6:46 ` Michal Hocko 2021-07-29 12:57 ` [PATCH 3/5] mm, memcg: save some atomic ops when flush is already true Miaohe Lin 2021-07-29 12:57 ` Miaohe Lin 2021-07-29 14:40 ` Shakeel Butt 2021-07-29 14:40 ` Shakeel Butt 2021-07-30 2:37 ` Muchun Song 2021-07-30 2:37 ` Muchun Song 2021-07-30 3:07 ` Roman Gushchin 2021-07-30 3:07 ` Roman Gushchin 2021-07-30 6:51 ` Michal Hocko 2021-07-30 6:51 ` Michal Hocko 2021-07-29 12:57 ` [PATCH 4/5] mm, memcg: avoid possible NULL pointer dereferencing in mem_cgroup_init() Miaohe Lin 2021-07-29 12:57 ` Miaohe Lin 2021-07-29 13:52 ` Matthew Wilcox 2021-07-29 13:52 ` Matthew Wilcox 2021-07-30 1:50 ` Miaohe Lin 2021-07-30 1:50 ` Miaohe Lin 2021-07-30 3:12 ` Roman Gushchin 2021-07-30 3:12 ` Roman Gushchin 2021-07-30 6:29 ` Miaohe Lin [this message] 2021-07-30 6:29 ` Miaohe Lin 2021-07-30 6:44 ` Michal Hocko 2021-07-30 6:44 ` Michal Hocko 2021-07-31 2:05 ` Miaohe Lin 2021-07-31 2:05 ` Miaohe Lin 2021-08-02 6:43 ` Michal Hocko 2021-08-02 6:43 ` Michal Hocko 2021-08-02 10:00 ` Miaohe Lin 2021-08-02 10:00 ` Miaohe Lin 2021-08-02 10:42 ` Michal Hocko 2021-08-02 10:42 ` Michal Hocko 2021-08-02 11:18 ` Miaohe Lin 2021-08-02 11:18 ` Miaohe Lin 2021-07-29 12:57 ` [PATCH 5/5] mm, memcg: always call __mod_node_page_state() with preempt disabled Miaohe Lin 2021-07-29 12:57 ` Miaohe Lin 2021-07-29 14:39 ` Shakeel Butt 2021-07-29 14:39 ` Shakeel Butt 2021-07-30 1:52 ` Miaohe Lin 2021-07-30 1:52 ` Miaohe Lin 2021-07-30 2:33 ` [External] " Muchun Song 2021-07-30 2:33 ` Muchun Song 2021-07-30 2:46 ` Miaohe Lin 2021-07-30 2:46 ` Miaohe Lin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2a9353e0-9ece-d8d5-1387-202b01b0fdad@huawei.com \ --to=linmiaohe@huawei.com \ --cc=akpm@linux-foundation.org \ --cc=alexs@kernel.org \ --cc=cgroups@vger.kernel.org \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=richard.weiyang@gmail.com \ --cc=shakeelb@google.com \ --cc=songmuchun@bytedance.com \ --cc=vdavydov.dev@gmail.com \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.