Re: [PATCH bpf 4/6] libbpf: ringbuf: Use compiler atomics

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] 32-bit monitoring applications using the BPF ring buffer on a 64-bit kernel will permanently stall after processing 4GB of events due to an unsigned long pointer type mismatch for producer/consumer positions.
--

commit b302f5c853774170c0ab9e37b85abcc4d647ac3b
Author: Tamir Duberstein <tamird@kernel.org>

libbpf: ringbuf: Use compiler atomics

This commit replaces architecture-specific smp_* helpers with portable compiler
atomics for shared memory accesses in the consumer-side ring buffer code.

> diff --git a/tools/lib/bpf/ringbuf.c b/tools/lib/bpf/ringbuf.c
> index b7adce37b5196..1c24a83f59d5c 100644
> --- a/tools/lib/bpf/ringbuf.c
> +++ b/tools/lib/bpf/ringbuf.c
[ ... ]
> @@ -284,14 +284,16 @@ static int64_t ringbuf_process_ring(struct ring *r, size_t n)
>  				err = r->sample_cb(r->ctx, sample, len);
>  				if (err < 0) {
>  					/* update consumer pos and bail out */
> -					smp_store_release(r->consumer_pos,
> -							  cons_pos);
> +					__atomic_store_n(r->consumer_pos,
> +							 cons_pos,
> +							 __ATOMIC_RELEASE);
>  					return err;
>  				}
>  				cnt++;
>  			}
>  
> -			smp_store_release(r->consumer_pos, cons_pos);
> +			__atomic_store_n(r->consumer_pos, cons_pos,
> +					 __ATOMIC_RELEASE);

[Severity: High]
This isn't a bug introduced by this patch, but does this write to
consumer_pos safely handle a 32-bit userspace application running on a
64-bit kernel?

In the kernel, struct bpf_ringbuf defines consumer_pos and producer_pos as
unsigned long, which are 64 bits. However, in libbpf's struct ring,
consumer_pos is mapped as an unsigned long pointer, which is only 32 bits
in a 32-bit userspace environment.

When the 32-bit user process updates consumer_pos via __atomic_store_n(), it
only overwrites the lower 32 bits of the 64-bit value on little-endian
systems. Once the true consumer position exceeds 4GB, the userspace 32-bit
value wraps to 0. Writing 0 to the lower 32 bits while the upper 32 bits
remain 0 causes the kernel to see consumer_pos drop to 0, while the 64-bit
producer_pos continues climbing past 4GB.

This causes the kernel's bpf_ringbuf_has_space() to see a delta larger than
the ring buffer mask, incorrectly treating the buffer as completely full and
permanently dropping all subsequent events for that buffer.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-bpf-ringbuf-fixes-v1-0-e623481cb724@kernel.org?part=4