All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ziyang Men" <ziyang.meme@gmail.com>
Cc: mkoutny@suse.com, tj@kernel.org, hannes@cmpxchg.org, bpf@vger.kernel.org
Subject: Re: [PATCH 3/3] selftests/bpf: add memcg_stat_churn_percpu BPF-vs-memory.stat benchmark under cross-CPU churn
Date: Sat, 04 Jul 2026 05:04:28 +0000	[thread overview]
Message-ID: <20260704050429.328271F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260704045617.487664-4-ziyang.meme@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Forked long-running child processes lack a parent-death signal, leading to runaway CPU-bound orphans if the test runner is forcefully terminated.
--

commit 0078545540e155786a22dbc2aaffa44f31944e3b
Author: Ziyang Men <ziyang.meme@gmail.com>

selftests/bpf: add memcg_stat_churn_percpu BPF-vs-memory.stat benchmark under cross-CPU churn

This commit introduces a new test_progs benchmark to evaluate memory-cgroup
statistics reading under cross-CPU churn. It forks multiple churner child
processes that migrate across CPUs and constantly allocate and free memory.

> diff --git a/tools/testing/selftests/bpf/prog_tests/memcg_stat_churn_percpu.c b/tools/testing/selftests/bpf/prog_tests/memcg_stat_churn_percpu.c
> new file mode 100644
> index 0000000000000..16c3f261c8780
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/memcg_stat_churn_percpu.c

[ ... ]

> +static void churner_child(const struct cg_node *leaf, int base, int k,
> +			  size_t region_bytes, size_t resident_bytes)
> +{
> +	int c_pool = n_cpu - n_reserved;
> +	void *resident;
> +	int j = 0;

[ ... ]

> +	if (write(churn_ready[1], "x", 1) != 1)
> +		_exit(3);
> +	close(churn_ready[1]);	/* so a sibling's early death yields EOF, not a parent hang */
> +
> +	while (!ctl->stop) {
> +		void *p;
> +
> +		/* migrate to the next of our K CPUs, then dirty the leaf there */

[Severity: Medium]
Will these child processes run indefinitely as CPU-bound orphans if the test
runner is abruptly terminated?

Since the loop relies on the parent safely executing the cleanup path to set
ctl->stop = 1, a hard crash or a timeout (like a SIGKILL from a CI system)
could leave these processes running forever.

Would it make sense to call prctl(PR_SET_PDEATHSIG, SIGKILL) early in this
function so the kernel automatically cleans them up if the parent dies?

> +		pin_cpu(cpu_list[n_reserved + (base + j) % c_pool]);
> +		if (++j == k)
> +			j = 0;
> +
> +		p = mmap(NULL, region_bytes, PROT_READ | PROT_WRITE,
> +			 MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260704045617.487664-1-ziyang.meme@gmail.com?part=3

  reply	other threads:[~2026-07-04  5:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-04  4:56 [PATCH 0/3] selftests/bpf: compare BPF and memory.stat memcg stat readers Ziyang Men
2026-07-04  4:56 ` [PATCH 1/3] selftests/bpf: add memcg_stat_reader BPF-vs-memory.stat benchmark Ziyang Men
2026-07-04  5:06   ` sashiko-bot
2026-07-04  4:56 ` [PATCH 2/3] selftests/bpf: add memcg_stat_churn BPF-vs-memory.stat benchmark under churn Ziyang Men
2026-07-04  5:39   ` bot+bpf-ci
2026-07-04  4:56 ` [PATCH 3/3] selftests/bpf: add memcg_stat_churn_percpu BPF-vs-memory.stat benchmark under cross-CPU churn Ziyang Men
2026-07-04  5:04   ` sashiko-bot [this message]
2026-07-04  5:58   ` bot+bpf-ci
2026-07-07  0:17 ` [PATCH 0/3] selftests/bpf: compare BPF and memory.stat memcg stat readers Eduard Zingerman
2026-07-07  1:50   ` Shakeel Butt
2026-07-07  9:21     ` Eduard Zingerman

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=20260704050429.328271F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=mkoutny@suse.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tj@kernel.org \
    --cc=ziyang.meme@gmail.com \
    /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.