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
