On Wed, Sep 16, 2026 at 4:47 PM Andrew Morton <[email protected]> wrote: > > On Wed, 16 Sep 2026 22:21:25 +0000 Bill Wendling <[email protected]> wrote: > > > Converting some strlcat() call sites seq_buf need behavior seq_buf doesn't > > currently provide, either directly or without introducing subtle bugs: > > > > - seq_buf_strlen(): seq_buf_used() reports the full buffer size when the > > buffer is completely filled, even though seq_buf_str() then overwrites > > the > > final byte with a NUL terminator, leaving only size - 1 bytes of > > actual content. Callers that need the true length of the > > NUL-terminated string have to fall back to strlen(seq_buf_str(s)). > > seq_buf_strlen() mirrors seq_buf_str()'s NUL-termination logic but > > returns > > the resulting string's length directly. > > > > - seq_buf_init_append(): seq_buf_init() always clears the buffer it's given > > via seq_buf_clear(). Code migrating from strlcat(buf, ...), which > > appends to whatever @buf already contains, can't use seq_buf_init() > > without silently discarding that existing content. seq_buf_init_append() > > preserves it and positions the seq_buf to append after it. > > > > - seq_buf_puts_trunc(): seq_buf_puts() (like seq_buf_printf() and friends) > > writes nothing at all if the string doesn't fully fit, whereas strlcat() > > always copies as much of the source as there is room for. Converting a > > strlcat() call site that relied on that partial-copy behavior to > > plain seq_buf_puts() can silently drop content that used to survive > > truncated. seq_buf_puts_trunc() keeps the leading bytes of the string > > that fit. > > > > ... > > > > include/linux/seq_buf.h | 60 +++++++++++++++++++++++++++++++++++++++++ > > lib/seq_buf.c | 35 ++++++++++++++++++++++++ > > 2 files changed, 95 insertions(+) > > This seems a lot of code for enabling some strlcat removals. How many > is "some"? If "3" then perhaps do something different at those > callsites? > In the series of patches I have in the wings (I sent one version, but it was a bit scattered and need to be resent), there are roughly 7 patches which use them, some more than once. While the impetus for these new functions are to help streamline the removal of the remaining strlcat, I believe Kees suggested these in order to keep the mathematics involved in keeping the seq_bufs correct was behind the API, rather than relying upon each user to get the math "correct". (Kees, please correct me if I'm wrong.)
> Sashiko had a couple of comments: > > https://sashiko.dev/#/patchset/[email protected] > I'll look into them. > Should these new functions be added to lib/tests/seq_buf_kunit.c? Yes. I'll send a followup with the Sashiko comments addressed and the KUnit tests added. Share and enjoy! -bw
