[PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions

[PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions

[fffsqian]

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.

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
-- 
2.25.1

Re: [PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions

[Qi Zheng]

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

Re: Re: [PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions

[傅清爽]

[-- Attachment #1: Type: text/html, Size: 6021 bytes --]

Re: [PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions

[Muchun Song]

> On Jun 25, 2026, at 11:01, 傅清爽 <fuqingshuang@kylinos.cn> wrote:
> 
> Hi Qi, 
>  
> Thank you very much for your detailed analysis and patient explanation. 
> I fully understand your point that the existing caller constraints guarantee shrinker_info cannot be NULL here, and this NULL check is unnecessary defensive code.

Thanks for your contribution! I have a couple of quick suggestions to
help things go smoother:

- Please take a closer look at our community communication guidelines,
  as we rely on plain-text-based replies here.

- For any issues you're not completely sure about, it would be awesome
  if you could run a quick validation yourself before sending out a patch.
  Maintainers' time is quite limited, so this helps everyone save a lot
  of energy and speeds up the review process.

Thanks for understanding, and looking forward to your next patch!

Thanks,
Muchun

Re:Re: [PATCH 1/1] mm/shrinker: add NULL checks after rcu_dereference() in shrinker bit functions

[fffsqian]

At 2026-06-26 11:49:13, "Muchun Song" <muchun.song@linux.dev> wrote:
>
>Thanks for your contribution! I have a couple of quick suggestions to
>help things go smoother:
>
>- Please take a closer look at our community communication guidelines,
>  as we rely on plain-text-based replies here.
>
>- For any issues you're not completely sure about, it would be awesome
>  if you could run a quick validation yourself before sending out a patch.
>  Maintainers' time is quite limited, so this helps everyone save a lot
>  of energy and speeds up the review process.
>
>Thanks for understanding, and looking forward to your next patch!
>
>Thanks,
>Muchun

Hi,

Thank you very much for your kind reminders and valuable suggestions.

I will strictly follow the plain-text reply specification for all future mailing list communications.
Meanwhile, I will do more sufficient code analysis and self-verification before submitting patches to avoid inaccurate problem description and unnecessary review cost.

Looking forward to submitting more qualified patches later.

Best regards,
Qingshuang Fu