From: sashiko-bot@kernel.org
To: "Emil Tsalapatis" <emil@etsalapatis.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 2/6] selftests/bpf: libarena: Inline nonatomic bitmap operations
Date: Mon, 17 Aug 2026 19:26:02 +0000 [thread overview]
Message-ID: <20260817192602.820C51F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260817191616.11071-3-emil@etsalapatis.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message explicitly states that writes are marked with WRITE_ONCE(), but the implementation uses raw volatile pointer casts instead.
--
--- Patch [2]: [PATCH 2/6] selftests/bpf: libarena: Inline nonatomic bitmap operations ---
commit 04b634add8119906bf065c817d1ba95b1411fb60
Author: Emil Tsalapatis <emil@etsalapatis.com>
selftests/bpf: libarena: Inline nonatomic bitmap operations
This commit moves the non-atomic bitmap operations to be static inline
functions in the header to reduce function call overhead. It also updates
these operations to supposedly use READ_ONCE() and WRITE_ONCE() to prevent
compiler optimizations.
> diff --git a/tools/testing/selftests/bpf/libarena/include/libarena/bitmap.h b/tools/testing/selftests/bpf/libarena/include/libarena/bitmap.h
> index 8c5936ae9958c..163e2b83d9431 100644
> --- a/tools/testing/selftests/bpf/libarena/include/libarena/bitmap.h
> +++ b/tools/testing/selftests/bpf/libarena/include/libarena/bitmap.h
[ ... ]
> @@ -33,3 +32,27 @@ void bmp_copy(size_t bits, struct arena_bitmap __arena *dst, struct arena_bitmap
> bool bmp_intersects(size_t bits, struct arena_bitmap __arena *arg1, struct arena_bitmap __arena *arg2);
> bool bmp_subset(size_t bits, struct arena_bitmap __arena *big, struct arena_bitmap __arena *small);
> void bmp_print(size_t bits, struct arena_bitmap __arena *bmp);
> +
> +static __always_inline
> +void __bmp_set_bit(u32 bit, struct arena_bitmap __arena *bmp)
> +{
> + volatile u64 __arena *word = &bmp->bits[BIT_WORD(bit)];
> +
> + *word |= BIT_MASK(bit);
> +}
[Severity: Medium]
The commit message explicitly states that writes are marked with WRITE_ONCE(),
but this function uses a raw volatile pointer cast instead. Should this be
updated to use WRITE_ONCE() to match the commit description?
> +
> +static __always_inline
> +void __bmp_clear_bit(u32 bit, struct arena_bitmap __arena *bmp)
> +{
> + volatile u64 __arena *word = &bmp->bits[BIT_WORD(bit)];
> +
> + *word &= ~BIT_MASK(bit);
> +}
[Severity: Medium]
Similarly here, a raw volatile pointer cast is used rather than WRITE_ONCE().
Does this code intend to use explicit WRITE_ONCE() as promised in the commit
message?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260817191616.11071-1-emil@etsalapatis.com?part=2
next prev parent reply other threads:[~2026-08-17 19:26 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 [this message]
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
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=20260817192602.820C51F00A3A@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.