From: sashiko-bot@kernel.org
To: linuszeng <linuszeng@tencent.com>
Cc: dri-devel@lists.freedesktop.org, tj@kernel.org, mkoutny@suse.com,
hannes@cmpxchg.org
Subject: Re: [PATCH v2 2/3] mm: page_counter: track protection state in page_counter_protection
Date: Wed, 09 Sep 2026 09:55:45 +0000 [thread overview]
Message-ID: <20260909095546.11DAA1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260909-descriptive-name-v2-2-d7dd7c099049@tencent.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Concurrent dmem cgroup eviction can observe a partially initialized pool and trigger a NULL pointer dereference.
--
commit 505dda1717b6dcbcc1903e6c7cc5e90077d70bb6
Author: linuszeng <linuszeng@tencent.com>
Subject: mm: page_counter: track protection state in page_counter_protection
This patch moves the read/write side of hierarchical protection from struct
page_counter to struct page_counter_protection. It updates
propagate_protected_usage and calculate_protection, along with accessors to
operate on the new context structure. The patch intends to introduce no
functional changes.
> diff --git a/mm/page_counter.c b/mm/page_counter.c
> index 38cb99f5f50ed..401201c8e3902 100644
> --- a/mm/page_counter.c
> +++ b/mm/page_counter.c
[ ... ]
> @@ -463,23 +479,24 @@ void page_counter_calculate_protection(struct page_counter *root,
> return;
>
> if (parent == root) {
> - counter->emin = READ_ONCE(counter->min);
> - counter->elow = READ_ONCE(counter->low);
> + prot->emin = READ_ONCE(prot->min);
> + prot->elow = READ_ONCE(prot->low);
> return;
> }
>
> + parent_prot = parent->prot;
[Severity: High]
This is a pre-existing issue, but could this code encounter a null pointer
dereference if concurrent dmem cgroup eviction observes a partially
initialized pool?
Looking at alloc_pool_single in kernel/cgroup/dmem.c, a new pool is
published to the RCU-protected pools list before its parent link is fully
established:
alloc_pool_single()
...
list_add_tail_rcu(&pool->css_node, &dmemcs->pools);
...
If a concurrent thread running dmem_cgroup_state_evict_valuable or
dmem_cgroup_below_min iterates over the cgroup descendants via
css_for_each_descendant_pre, it can find this partially initialized pool and
pass it to page_counter_calculate_protection.
Since counter->parent is null and does not match the root argument, the
early return above is skipped, leading to a dereference of parent->prot
here when parent is null.
Does the eviction path need to synchronize with the completion of pool
initialization, or should page_counter_calculate_protection check if parent
is null before dereferencing it?
> parent_usage = page_counter_read(parent);
>
> - WRITE_ONCE(counter->emin, effective_protection(usage, parent_usage,
> - READ_ONCE(counter->min),
> - READ_ONCE(parent->emin),
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-descriptive-name-v2-0-d7dd7c099049@tencent.com?part=2
next prev parent reply other threads:[~2026-09-09 9:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 9:44 [PATCH v2 0/3] mm: page_counter: move hierarchical protection out of struct page_counter linuszeng via B4 Relay
2026-09-09 9:44 ` linuszeng
2026-09-09 9:44 ` [PATCH v2 1/3] mm: page_counter: add page_counter_protection struct and init API linuszeng via B4 Relay
2026-09-09 9:44 ` linuszeng
2026-09-09 9:44 ` [PATCH v2 2/3] mm: page_counter: track protection state in page_counter_protection linuszeng via B4 Relay
2026-09-09 9:44 ` linuszeng
2026-09-09 9:55 ` sashiko-bot [this message]
2026-09-09 9:44 ` [PATCH v2 3/3] mm: page_counter: drop protection fields from struct page_counter linuszeng via B4 Relay
2026-09-09 9:44 ` linuszeng
2026-09-11 15:17 ` [PATCH v2 0/3] mm: page_counter: move hierarchical protection out of " Michal Koutný
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=20260909095546.11DAA1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hannes@cmpxchg.org \
--cc=linuszeng@tencent.com \
--cc=mkoutny@suse.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tj@kernel.org \
/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.