[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZONz8Zqwg4cuCGCe@casper.infradead.org>
Date: Mon, 21 Aug 2023 15:25:53 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Anastasia Belova <abelova@...ralinux.ru>
Cc: Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Shakeel Butt <shakeelb@...gle.com>,
Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH] mm: memcomtrol: add warning in case of rtpn = NULL
On Mon, Aug 21, 2023 at 05:20:51PM +0300, Anastasia Belova wrote:
> kzalloc_node may return NULL. So rtpn should be
> checked before dereference in mem_cgroup_init.
What good will this do?
>
> rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL, node);
> + WARN_ON(!rtpn);
>
> rtpn->rb_root = RB_ROOT;
so you'll get a warning right before you get a crash, which will provide
exactly the same information. And you'd already have a warning that
the memory allocation had failed (because __GFP_NOWARN wasn't set).
So you've increased the amount of data from 2 dumps to 3 without providing
any neww information.
If you _did_ something to avoid the crash, there might be a point to
this, but the fact is that small GFP_KERNEL allocations _don't_ fail.
You need to teach your tool that, or you'll be overwhelmed with
false positives.
Powered by blists - more mailing lists