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

[Kees Cook]

On Mon, Oct 05, 2026 at 01:34:10PM +0200, Alejandro Colomar wrote:
> > Yeah, reasonable. :) For v5 I've added this to seq_buf_str()'s kernel-doc:
> >
> >  * A zero-sized seq_buf has nowhere to put a NUL, so the empty string
> >  * is returned instead of writing to @s->buffer. Any other seq_buf
> >  * returns @s->buffer, even when it holds an empty string, so callers
> >  * always get their own buffer back.
>
> Are such buffers actually used on purpose anywhere?  Why not keep the
> WARN_ON?

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).

Greg asked about the WARN_ON() in v2[1]: a size that comes from a device
or from userspace would have to be checked before every seq_buf_init(),
or it becomes a crash under panic_on_warn, and an empty buffer can just
hold the empty string. So the accessors do that instead.

[1] https://lore.kernel.org/all/2026091953-cherub-empty-ef35@gregkh/

-Kees

-- 
Kees Cook