Re: [PATCH v4 05/11] seq_buf: Add seq_buf_strlen()
flat view
From: Kees Cook <kees@kernel.org>
Date: 2026-10-05 15:58:46
Also in:
bpf, linux-doc, linux-hardening, linux-trace-kernel, linuxppc-dev, lkml, nvdimm
On Mon, Oct 05, 2026 at 01:34:10PM +0200, Alejandro Colomar wrote:
quoted
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/ (local) -Kees -- Kees Cook