Re: [PATCH v2 1/2] mm: multi-gen LRU: use mem_cgroup_lruvec() in get_lruvec()

[Barry Song]

On Tue, Oct 27, 2026 at 4:23 AM Siddharth Chintamaneni
<sidchintamaneni@xxxxxxxxx> wrote:
>
> Andrew Morton noted that get_lruvec() has the same pattern as
> lru_gen_shrink_node(): when memcg is disabled on the command line
> (cgroup_disable=memory), it returns &pgdat->__lruvec directly instead of
> going through mem_cgroup_lruvec(), which initializes lruvec->pgdat.
>
> In practice all callers of get_lruvec() run after kswapd_init() has
> already initialized pgdat->__lruvec.pgdat on every N_MEMORY node, so
> this is not a runtime bug. Have get_lruvec() delegate to
> mem_cgroup_lruvec() directly.

Somehow, I feel this changelog is a bit weird. The earlier
description doesn't really justify the final sentence:
"Have get_lruvec() delegate to mem_cgroup_lruvec() directly."

Can we change it to the below?

The patch was initially developed to address a possible NULL
reference [1].

Andrew Morton reported that get_lruvec() has the same problem as
lru_gen_shrink_node(): when memcg is disabled on the command line
(cgroup_disable=memory), it returns &pgdat->__lruvec directly and so
bypasses the initialization of lruvec->pgdat. The MGLRU debugfs
interface calls get_lruvec(), then dereferences the pgdat pointer in
lru_gen_seq_show() and other paths, so these can hit the same NULL
dereference.

In practice, we found that this cannot happen, as all callers of
get_lruvec() run after kswapd_init() has initialized
pgdat->__lruvec.pgdat on every N_MEMORY node. Therefore, this
is not a runtime bug.

However, it would still be good to clean up get_lruvec() by
removing the MGLRU-specific code and having it delegate
directly to mem_cgroup_lruvec().

[1] https://lore.kernel.org/linux-mm/20261017050928.128582-2-sidchintamaneni@xxxxxxxxx/

>
> Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
> Signed-off-by: Siddharth Chintamaneni <sidchintamaneni@xxxxxxxxx>
> Signed-off-by: Hardik Garg <hargar@xxxxxxxxxxxxxxxxxxx>
> ---

With the changelog updated as suggested,

Reviewed-by: Barry Song <baohua@xxxxxxxxxx>