Re: [PATCH bpf-next] bpf: Fix stream capacity leak and spurious -ENOSPC in bpf_stream_stage_commit

[Khawar Ahemad <ahemadkhawar123@gmail.com>]

Hi Sashiko reviewer,

Thanks for the thoughtful analysis. Addressing both points:

1. Regarding 0-byte elements (Low):
A 0-byte element in BPF streams carries no payload and no delimiter
(unlike NUL-terminated strings in userspace, streams are raw byte logs).
When bpf_stream_read() encounters a 0-byte element, min(0, rem_len) is 0,
copy_to_user() copies 0 bytes, and the element is immediately popped and
freed. Staging and committing a purely 0-byte stage transfers zero bytes
of data to readers; returning early when ss->len == 0 safely avoids
unnecessary atomic operations and lock contention on stream->log.

2. Regarding the rollback path and commit description (Medium):
In normal sequential execution, ss->len > 0 implies ss->log is non-empty
because ss->len is only incremented upon successful element enqueue.
The if (!list) rollback check is defensive programming: in the unpatched
code, if list was NULL, the function returned 0 without considering any
capacity consumed. Adding bpf_stream_release_capacity() ensures that even
under abnormal or future decoupled states, capacity accounting remains
strictly symmetric with queue state.

The primary immediate functional fix is preventing spurious -ENOSPC:
when stream->capacity is at BPF_STREAM_MAX_CAPACITY, calling
bpf_stream_consume_capacity(stream, 0) returned -ENOSPC due to the
atomic_read(&stream->capacity) >= BPF_STREAM_MAX_CAPACITY check,
incorrectly failing zero-byte stage commits.

Thanks,
Khawar Ahemad <ahemadkhawar123@gmail.com>