All of lore.kernel.org
 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 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.