From: bot+bpf-ci@kernel.org
To: hui.zhu@linux.dev,akpm@linux-foundation.org,hannes@cmpxchg.org,mhocko@kernel.org,roman.gushchin@linux.dev,shakeel.butt@linux.dev,muchun.song@linux.dev,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,martin.lau@linux.dev,eddyz87@gmail.com,song@kernel.org,yonghong.song@linux.dev,john.fastabend@gmail.com,kpsingh@kernel.org,sdf@fomichev.me,haoluo@google.com,jolsa@kernel.org,shuah@kernel.org,peterz@infradead.org,ojeda@kernel.org,nathan@kernel.org,kees@kernel.org,tj@kernel.org,jeffxu@chromium.org,mkoutny@suse.com,kernel@jfarr.cc,brauner@kernel.org,rdunlap@infradead.org,brgerst@gmail.com,masahiroy@kernel.org,linux-kernel@vger.kernel.org,linux-mm@kvack.org,cgroups@vger.kernel.org,bpf@vger.kernel.org,linux-kselftest@vger.kernel.org
Cc: zhuhui@kylinos.cn,geliang@kernel.org,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [RFC PATCH 1/3] memcg: add eBPF struct ops support for memory charging
Date: Wed, 19 Nov 2025 02:10:05 +0000 (UTC) [thread overview]
Message-ID: <bb24c9ee360a4538d3aa5f00091586fe0d7ae4b7277ea8efe866457954a75696@mail.kernel.org> (raw)
In-Reply-To: <15f95166c6c516f303f3092e74c88ace5164bdf0.1763457705.git.zhuhui@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 4deda3362..104c9e930 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -68,6 +68,7 @@
> #include <net/ip.h>
> #include "slab.h"
> #include "memcontrol-v1.h"
> +#include "memcontrol_bpf.h"
>
> #include <linux/uaccess.h>
>
> @@ -2301,13 +2302,14 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> int nr_retries = MAX_RECLAIM_RETRIES;
> struct mem_cgroup *mem_over_limit;
> struct page_counter *counter;
> - unsigned long nr_reclaimed;
> + unsigned long nr_reclaime, nr_reclaimed;
> bool passed_oom = false;
> unsigned int reclaim_options = MEMCG_RECLAIM_MAY_SWAP;
> bool drained = false;
> bool raised_max_event = false;
> unsigned long pflags;
> bool allow_spinning = gfpflags_allow_spinning(gfp_mask);
> + bool charge_done = false;
>
> retry:
> if (consume_stock(memcg, nr_pages))
> @@ -2320,20 +2322,30 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> if (!do_memsw_account() ||
> page_counter_try_charge(&memcg->memsw, batch, &counter)) {
> if (page_counter_try_charge(&memcg->memory, batch, &counter))
> - goto done_restock;
> - if (do_memsw_account())
> - page_counter_uncharge(&memcg->memsw, batch);
> - mem_over_limit = mem_cgroup_from_counter(counter, memory);
> + charge_done = true;
> + else {
> + if (do_memsw_account())
> + page_counter_uncharge(&memcg->memsw, batch);
> + mem_over_limit = mem_cgroup_from_counter(counter, memory);
> + }
> } else {
> mem_over_limit = mem_cgroup_from_counter(counter, memsw);
> reclaim_options &= ~MEMCG_RECLAIM_MAY_SWAP;
> }
>
> - if (batch > nr_pages) {
> + if (!charge_done && batch > nr_pages) {
> batch = nr_pages;
> goto retry;
> }
>
> + nr_reclaime = bpf_try_charge_memcg(memcg, gfp_mask, nr_pages,
> + mem_over_limit,
> + reclaim_options,
> + charge_done);
^^^^^^^^^^^^
When charge succeeds (charge_done = true), mem_over_limit is never
initialized but gets passed to bpf_try_charge_memcg(). Looking at
memcontrol_bpf.h, the BPF verifier allows read access to all fields
in struct try_charge_memcg via bpf_tracing_btf_ctx_access() (only
write access to nr_pages is restricted by memcg_ops_btf_struct_access).
Can the BPF program read this uninitialized pointer value? This would
leak kernel stack data to the BPF program.
> +
> + if (charge_done)
> + goto done_restock;
[ ... ]
> diff --git a/mm/memcontrol_bpf.h b/mm/memcontrol_bpf.h
> new file mode 100644
> index 000000000..ee2815fc3
> --- /dev/null
> +++ b/mm/memcontrol_bpf.h
[ ... ]
> +static inline unsigned long
> +bpf_try_charge_memcg(struct mem_cgroup *memcg,
> + gfp_t gfp_mask,
> + unsigned int nr_pages,
> + struct mem_cgroup *mem_over_limit,
> + unsigned int reclaim_options,
> + bool charge_done)
> +{
> + struct memcg_ops *ops;
> + struct try_charge_memcg tcm;
> + int update_nr_pages;
> +
> + if (likely(!static_branch_unlikely(&memcg_bpf_enable)))
> + goto out;
> +
> + ops = memcg_ops_get();
> + if (unlikely(!ops))
> + goto out;
> +
> + tcm.memcg = memcg;
> + tcm.gfp_mask = gfp_mask;
> + tcm.nr_pages = nr_pages;
> + tcm.mem_over_limit = mem_over_limit;
^^^^^^^^^^^^^^^
Here mem_over_limit gets copied into the tcm struct, which is then
passed to the BPF program at the line below.
> + tcm.reclaim_options = reclaim_options;
> + tcm.charge_done = charge_done;
> +
> + update_nr_pages = ops->try_charge_memcg(&tcm);
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19486904708
next prev parent reply other threads:[~2025-11-19 2:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 1:34 [RFC PATCH 0/3] Memory Controller eBPF support Hui Zhu
2025-11-19 1:34 ` [RFC PATCH 1/3] memcg: add eBPF struct ops support for memory charging Hui Zhu
2025-11-19 2:10 ` bot+bpf-ci [this message]
2025-11-19 16:07 ` Tejun Heo
2025-11-19 1:34 ` [RFC PATCH 2/3] selftests/bpf: add memcg eBPF struct ops test Hui Zhu
2025-11-19 2:19 ` bot+bpf-ci
2025-11-19 1:34 ` [RFC PATCH 3/3] samples/bpf: add example memcg eBPF program Hui Zhu
2025-11-19 2:19 ` bot+bpf-ci
2025-11-20 3:04 ` [RFC PATCH 0/3] Memory Controller eBPF support Roman Gushchin
2025-11-20 9:29 ` hui.zhu
2025-11-20 19:20 ` Michal Hocko
2025-11-21 2:46 ` hui.zhu
2025-11-25 12:12 ` Michal Hocko
2025-11-25 12:39 ` hui.zhu
2025-11-25 12:55 ` Michal Hocko
2025-11-26 3:05 ` hui.zhu
2025-11-26 16:01 ` Michal Hocko
2025-11-27 8:51 ` hui.zhu
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=bb24c9ee360a4538d3aa5f00091586fe0d7ae4b7277ea8efe866457954a75696@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=brgerst@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=geliang@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=haoluo@google.com \
--cc=hui.zhu@linux.dev \
--cc=ihor.solodrai@linux.dev \
--cc=jeffxu@chromium.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kees@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=masahiroy@kernel.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nathan@kernel.org \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=sdf@fomichev.me \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=yonghong.song@linux.dev \
--cc=zhuhui@kylinos.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox