From: sashiko-bot@kernel.org
To: "Emil Tsalapatis" <emil@etsalapatis.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 5/6] selftests/bpf: libarena: Add a benchmark for malloc()/calloc()
Date: Mon, 17 Aug 2026 19:31:34 +0000 [thread overview]
Message-ID: <20260817193134.D78D91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260817191616.11071-6-emil@etsalapatis.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The benchmark incorrectly reports the 'allocations per second' metric as 'invocations', and includes an unmatched closing parenthesis.
- [Medium] Missing bounds check causes silent 32-bit integer truncation for the `--nallocs` argument.
- [Low] An unsigned validation value is formatted with a signed `%ld` specifier, causing it to print negative numbers on error.
--
--- Patch [5]: [PATCH 5/6] selftests/bpf: libarena: Add a benchmark for malloc()/calloc() ---
commit cfe60c8125bcfe8399db973cf6b5a739e50079d3
Author: Emil Tsalapatis <emil@etsalapatis.com>
selftests/bpf: libarena: Add a benchmark for malloc()/calloc()
Add a benchmark for measuring the performance of the malloc()/calloc()
arena allocator calls. This is useful as a basic allocator performance
check that we can easily expand later. As with the regular arena
allocator, focus on sub-page allocations that cannot be satisfied
efficiently with the BPF arena page allocation code.
> diff --git a/tools/testing/selftests/bpf/benchs/bench_libarena.c b/tools/testing/selftests/bpf/benchs/bench_libarena.c
> new file mode 100644
> index 0000000000000..24e432244bf5d
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/benchs/bench_libarena.c
> @@ -0,0 +1,210 @@
[ ... ]
> +static error_t parse_arg(int key, char *arg, struct argp_state *state)
> +{
> + unsigned long value;
> +
> + switch (key) {
> + case ARG_LIBARENA_ALLOC_SIZE:
> + value = strtoull(arg, NULL, 10);
> + if (!value || value >= UINT_MAX) {
> + fprintf(stderr, "invalid alloc_size: %ld", value);
[Severity: Low]
Does this print a negative number on overflow since value is an unsigned long
and the format specifier is %ld instead of %lu?
> + argp_usage(state);
> + }
> + args.alloc_size = value;
> + break;
> + case ARG_LIBARENA_NALLOCS:
> + args.nallocs = strtoull(arg, NULL, 10);
[Severity: Medium]
Since args.nallocs is parsed as a 64-bit value without upper bounds validation,
and ctx.skel->bss->bench_nallocs is a 32-bit u32, does this result in silent
32-bit integer truncation when copying it later in setup_common()?
> + break;
> + default:
> + return ARGP_ERR_UNKNOWN;
> + }
> +
> + return 0;
> +}
[ ... ]
> +static void report_final(struct bench_res res[], int res_cnt)
> +{
> + unsigned long duration_ns = 0;
> + long hits = 0;
> + int i;
> +
> + for (i = 0; i < res_cnt; i++) {
> + duration_ns += res[i].duration_ns;
> + hits += res[i].hits;
> + }
> +
> + if (!hits || !res_cnt) {
> + printf("Summary: no runs measured\n");
> + return;
> + }
> +
> + printf("Summary: %.3lf ns/op, %.0lf invocations for %u allocations/invocation)\n",
> + duration_ns / (double)hits, hits / (double)res_cnt,
> + ctx.skel->bss->bench_nallocs);
[Severity: Medium]
Since hits tracks the total number of allocations, does hits / res_cnt
incorrectly report the allocations metric as invocations?
Also, there is an unmatched closing parenthesis at the end of the format
string.
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260817191616.11071-1-emil@etsalapatis.com?part=5
next prev parent reply other threads:[~2026-08-17 19:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 19:16 [PATCH 0/6] selftests/bpf: Fixes and improvements for libarena Emil Tsalapatis
2026-08-17 19:16 ` [PATCH 1/6] selftests/bpf: libarena: Normalize SPDX headers across files Emil Tsalapatis
2026-08-17 19:21 ` sashiko-bot
2026-08-17 19:16 ` [PATCH 2/6] selftests/bpf: libarena: Inline nonatomic bitmap operations Emil Tsalapatis
2026-08-17 19:26 ` sashiko-bot
2026-08-17 20:25 ` bot+bpf-ci
2026-08-17 19:16 ` [PATCH 3/6] selftests/bpf: libarena: Disable IRQs during allocation Emil Tsalapatis
2026-08-17 19:28 ` sashiko-bot
2026-08-17 20:38 ` bot+bpf-ci
2026-08-17 19:16 ` [PATCH 4/6] selftests/bpf: libarena: Add calloc() call Emil Tsalapatis
2026-08-17 19:23 ` sashiko-bot
2026-08-17 20:25 ` bot+bpf-ci
2026-08-17 19:16 ` [PATCH 5/6] selftests/bpf: libarena: Add a benchmark for malloc()/calloc() Emil Tsalapatis
2026-08-17 19:31 ` sashiko-bot [this message]
2026-08-17 20:25 ` bot+bpf-ci
2026-08-17 19:16 ` [PATCH 6/6] selftests/bpf: libarena: Optimize and make public arena_memset Emil Tsalapatis
2026-08-17 20:25 ` bot+bpf-ci
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=20260817193134.D78D91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=emil@etsalapatis.com \
--cc=sashiko-reviews@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox