From: Qi Zheng <qi.zheng@linux.dev>
To: fffsqian@163.com, Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Qingshuang Fu <fuqingshuang@kylinos.cn>
Subject: Re: [PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions
Date: Wed, 24 Jun 2026 18:49:07 +0800 [thread overview]
Message-ID: <923f391a-d760-4d78-92d4-2e765aa226f3@linux.dev> (raw)
In-Reply-To: <20260624095527.277586-1-fffsqian@163.com>
Hi Qingshuang,
On 6/24/26 5:55 PM, fffsqian@163.com wrote:
> From: Qingshuang Fu <fuqingshuang@kylinos.cn>
>
> The functions set_shrinker_bit(), xchg_nr_deferred_memcg(), and
> add_nr_deferred_memcg() access shrinker_info fields immediately
> after rcu_dereference() without checking for NULL.
>
> This is inconsistent with shrink_slab_memcg() which properly checks
> "if (unlikely(!info)) goto unlock;" before accessing info fields.
>
> The shrinker_info can be NULL during memcg initialization or after
> shrinker_info expansion failure. Directly accessing info->map_nr_max
> or info->unit[] without NULL validation could cause kernel NULL
> pointer dereference and panic.
Really? Did you actually hit this issue, or are you able to reproduce
it? Or is it just spotted via code inspection?
The callers in all three of these places should guarantee that `info`
can not possibly be NULL. :(
Thanks,
Qi
>
> Fix this by adding proper NULL checks in all three functions to
> ensure consistent RCU protection and prevent potential crashes in
> the shrinker subsystem.
>
> Fixes: 307bececcd1205bcb ("mm: shrinker: add a secondary array for shrinker_info::{map, nr_deferred}")
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Dave Chinner <david@fromorbit.com>
> Cc: Qi Zheng <qi.zheng@linux.dev>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Muchun Song <muchun.song@linux.dev>
> Cc: linux-mm@kvack.org
> Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
> ---
> mm/shrinker.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/mm/shrinker.c b/mm/shrinker.c
> index 7082d01c8c9d..ecde3cc44459 100644
> --- a/mm/shrinker.c
> +++ b/mm/shrinker.c
> @@ -200,6 +200,8 @@ void set_shrinker_bit(struct mem_cgroup *memcg, int nid, int shrinker_id)
>
> rcu_read_lock();
> info = rcu_dereference(memcg->nodeinfo[nid]->shrinker_info);
> + if (unlikely(!info))
> + goto unlock;
> if (!WARN_ON_ONCE(shrinker_id >= info->map_nr_max)) {
> struct shrinker_info_unit *unit;
>
> @@ -208,6 +210,7 @@ void set_shrinker_bit(struct mem_cgroup *memcg, int nid, int shrinker_id)
> smp_mb__before_atomic();
> set_bit(shrinker_id_to_offset(shrinker_id), unit->map);
> }
> +unlock:
> rcu_read_unlock();
> }
> }
> @@ -258,6 +261,10 @@ static long xchg_nr_deferred_memcg(int nid, struct shrinker *shrinker,
>
> rcu_read_lock();
> info = rcu_dereference(memcg->nodeinfo[nid]->shrinker_info);
> + if (unlikely(!info)) {
> + rcu_read_unlock();
> + return 0;
> + }
> unit = info->unit[shrinker_id_to_index(shrinker->id)];
> nr_deferred = atomic_long_xchg(&unit->nr_deferred[shrinker_id_to_offset(shrinker->id)], 0);
> rcu_read_unlock();
> @@ -274,6 +281,10 @@ static long add_nr_deferred_memcg(long nr, int nid, struct shrinker *shrinker,
>
> rcu_read_lock();
> info = rcu_dereference(memcg->nodeinfo[nid]->shrinker_info);
> + if (unlikely(!info)) {
> + rcu_read_unlock();
> + return 0;
> + }
> unit = info->unit[shrinker_id_to_index(shrinker->id)];
> nr_deferred =
> atomic_long_add_return(nr, &unit->nr_deferred[shrinker_id_to_offset(shrinker->id)]);
>
> base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
prev parent reply other threads:[~2026-06-24 10:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 9:55 [PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions fffsqian
2026-06-24 10:49 ` Qi Zheng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=923f391a-d760-4d78-92d4-2e765aa226f3@linux.dev \
--to=qi.zheng@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=fffsqian@163.com \
--cc=fuqingshuang@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.