On Mon, Oct 05, 2026 at 07:59:26PM +0100, David Laight wrote:
> > static inline void
> > seq_buf_set_overflow(struct seq_buf *s)
> > {
> > + if (s->len < s->size)
> > + memset(s->buffer + s->len, 0, s->size - s->len);
>
> What is the performance impact of zeroing the buffer?
Overflow is never a fast path: it happens at most once per seq_buf
(after that len > size, so the memset is skipped), and it is already a
failure the caller has to handle.
It is also usually zero bytes. printf, bprintf, puts, putmem, and putc
all fill to the end before overflowing, so len == size and there is
nothing to clear. Only a writer handed the tail by seq_buf_get_buf()
that then gives up leaves anything behind (seq_buf_path() with d_path(),
or landlock's string_escape_mem()), and then the clear covers only the
space that writer was given, which it may have partly filled.
> I don't think it would be a good idea to be zeroing the buffer on entry
> either (I've not looked to see it that happens - but there will be PAGE_SIZE
> buffers (maybe 64k) that get a a small number of characters written to them).
Agreed, and it doesn't: seq_buf_init() writes a single NUL.
> Writing a single '\0' really ought to be enough.
It would be for seq_buf_str(), but once a seq_buf has overflowed,
seq_buf_used() reports the whole buffer, and seq_buf_print_seq() and
seq_buf_to_user() copy that many bytes. Whatever followed the NUL (the
path fragment d_path() left at the end, say) would still reach the
seq_file or userspace.
-Kees
--
Kees Cook
