[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201130134514.GL17338@dhcp22.suse.cz>
Date: Mon, 30 Nov 2020 14:45:14 +0100
From: Michal Hocko <mhocko@...e.com>
To: Muchun Song <songmuchun@...edance.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
Shakeel Butt <shakeelb@...gle.com>,
Roman Gushchin <guro@...com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
alex.shi@...ux.alibaba.com, alexander.h.duyck@...ux.intel.com,
Yafang Shao <laoar.shao@...il.com>, richard.weiyang@...il.com,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: [External] Re: [PATCH] mm/memcg: fix NULL pointer dereference at
workingset_eviction
On Mon 30-11-20 21:36:49, Muchun Song wrote:
> On Mon, Nov 30, 2020 at 9:23 PM Michal Hocko <mhocko@...e.com> wrote:
> >
> > On Mon 30-11-20 21:15:12, Muchun Song wrote:
> > > We found a case of kernel panic. The stack trace is as follows
> > > (omit some irrelevant information):
> > >
> > > BUG: kernel NULL pointer dereference, address: 00000000000000c8
> > > RIP: 0010:workingset_eviction+0x26b/0x450
> > > Call Trace:
> > > __remove_mapping+0x224/0x2b0
> > > shrink_page_list+0x8c2/0x14e0
> > > shrink_inactive_list+0x1bf/0x3f0
> > > ? do_raw_spin_unlock+0x49/0xc0
> > > ? _raw_spin_unlock+0xa/0x20
> > > shrink_lruvec+0x401/0x640
> > >
> > > This was caused by commit 76761ffa9ea1 ("mm/memcg: bail out early when
> > > !memcg in mem_cgroup_lruvec"). When the parameter of memcg is NULL, we
> > > should not use the &pgdat->__lruvec. So this just reverts commit
> > > 76761ffa9ea1 to fix it.
> > >
> > > Fixes: 76761ffa9ea1 ("mm/memcg: bail out early when !memcg in mem_cgroup_lruvec")
> >
> > I do not see any commits like that in the current Linus tree. Is this a
> > commit id from the linux-next? If yes, can we just fold it into the
> > respective patch in mmotm tree please?
>
> Yes. This commit is on the linux-next tree.
FYI, patches coming from mmotm are constantly rebased in linux-next so
the sha1 is meaningless and shouldn't be added as a reference in the
changelog.
> Of course can.
Thanks! I believe Andrew should be able to just pick up the patch and
make it -fix patch.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists