On Sun, 29 Jan 2023 10:44:51 +0800 Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> 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@xxxxxxxxxx>
> 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.
