> seq_buf: Add seq_buf_init_append() TL;DR: Commit message only: it says seq_buf_init() sets the buffer size to 0 via seq_buf_clear(), but it resets the length, not the size. The code is not reported as buggy.
> seq_buf: Add seq_buf_init_append() > > Several strlcat() call sites being converted to seq_buf need behavior > seq_buf doesn't currently provide. The normal seq_buf_init() always > sets the new buffer size to 0 via seq_buf_clear(). Code migrating from > strlcat(buf, ...), which appends to whatever buf already contains, > can't use seq_buf_init() without discarding that existing content. Add > seq_buf_init_append(), which preserves the existing contents and positions > the seq_buf to append after it. A buffer with no NUL within its size > starts out overflowed, as strlcat() treats it as already truncated. > Add KUnit tests for behavior coverage. > > Tests passed under qemu on ARCH=x86_64 with GCC 16.2.0 and CONFIG_KASAN=y, > and on big-endian ARCH=s390 with GCC s390x-linux-gnu 16.2.0. > > Assisted-by: LLM > Signed-off-by: Bill Wendling <[email protected]> > Reviewed-by: Andy Shevchenko <[email protected]> > Co-developed-by: Kees Cook <[email protected]> > Signed-off-by: Kees Cook <[email protected]> This isn't a bug in the code, but is the changelog accurate when it says seq_buf_init() "always sets the new buffer size to 0 via seq_buf_clear()"? seq_buf_init() stores the size it was given in s->size, and seq_buf_clear() leaves s->size alone. It only resets the length and terminates the first byte: static inline void seq_buf_clear(struct seq_buf *s) { s->len = 0; if (s->size) s->buffer[0] = '\0'; } Should the sentence say that seq_buf_init() always sets the length (s->len) to 0 via seq_buf_clear(), rather than the buffer size? --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37096036516
