Re: [PATCH v4 05/11] seq_buf: Add seq_buf_strlen()

On Mon, Oct 05, 2026 at 06:43:23PM +0200, Alejandro Colomar wrote:

quoted

Yes, though not often: the sched_ext debug dump builds a nested per-CPU
seq_buf from seq_buf_get_buf(), which returns a size of 0 once the dump
buffer has overflowed, and it handles that case on purpose (see the
"$s may already have overflowed" comment in kernel/sched/ext/ext.c).

Hmmmm, so IIUC, it is a sentinel value, and not really a buffer size?

It's the real size of what's left. seq_buf_get_buf() hands out the
unused tail of the seq_buf. Once that has overflowed there is no tail,
so it returns NULL for the buffer and 0 for the size, and sched_ext
initializes the nested seq_buf with both. So that case does get the NULL;
the 0 is how much room it has.

Did you consider not holding the size of the buffer, but rather an end
pointer?  It also allows you to find how much you can write to the
buffer, but has slightly better semantics: the end doesn't change if you
advance the position.  'end' can only change through reallocations
(which I don't know if you do in the kernel).

The size doesn't change either: it is set by seq_buf_init(), and writers
advance "len", an offset from the start of the buffer. seq_buf never
reallocates.

An end pointer wouldn't remove the empty case: buffer == end is the same
condition as size == 0, so the accessors would still need the check. It
also makes overflow harder to record. seq_buf marks it with len == size +
1, and the matching position pointer, end + 1, would be weird.

Changing the representation would also means changes outside
lib/seq_buf.c, since tracing reads seq.len and seq.size directly
(trace_seq treats a zero size as "not yet initialized", for one). I'm
not saying that's a good thing to bypass the API, but rather that such
a change should be its own series.

-Kees

-- 
Kees Cook