[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230129134815.21083b65ef3ae4c3e7fae8eb@linux-foundation.org>
Date: Sun, 29 Jan 2023 13:48:15 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Kefeng Wang <wangkefeng.wang@...wei.com>
Cc: Tejun Heo <tj@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Jan Kara <jack@...e.cz>, Shakeel Butt <shakeelb@...gle.com>,
Naoya Horiguchi <naoya.horiguchi@....com>,
<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
Ma Wupeng <mawupeng1@...wei.com>,
Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm: memcg: fix NULL pointer in
mem_cgroup_track_foreign_dirty()
On Sun, 29 Jan 2023 10:44:51 +0800 Kefeng Wang <wangkefeng.wang@...wei.com> wrote:
> As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"),
Merged in 2017.
> hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg
> could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could
> occurs a NULL pointer dereference, let's do not record the foreign
> writebacks for folio memcg is null in mem_cgroup_track_foreign() to
> fix it.
>
> Reported-by: Ma Wupeng <mawupeng1@...wei.com>
> Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing")
Merged in 2019.
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1688,10 +1688,13 @@ void mem_cgroup_track_foreign_dirty_slowpath(struct folio *folio,
> static inline void mem_cgroup_track_foreign_dirty(struct folio *folio,
> struct bdi_writeback *wb)
> {
> + struct mem_cgroup *memcg;
> +
> if (mem_cgroup_disabled())
> return;
>
> - if (unlikely(&folio_memcg(folio)->css != wb->memcg_css))
> + memcg = folio_memcg(folio);
> + if (unlikely(memcg && &memcg->css != wb->memcg_css))
> mem_cgroup_track_foreign_dirty_slowpath(folio, wb);
> }
Has this null deref actually been observed, or is this from code
inspection? (This is why it's nice to include the Link: after a
Reported-by!)
Do we have any theories why this took so many years to surface?
I'm confused about the mention of 18365225f044, but the Fixes: target
is a different commit. Please explain this?
Do you think the fix should be backported into earlier -stable kernels?
If so, it will need some rework due to the subsequent folio
conversion.
Powered by blists - more mailing lists