BPF List
 help / color / mirror / Atom feed
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

  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