Re: [PATCH v5 05/12] seq_buf: Clear what a writer did not claim when a seq_buf overflows

[Steven Rostedt]

On Tue, 6 Oct 2026 14:26:56 -0700
Kees Cook <kees@xxxxxxxxxx> wrote:

> 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.

Correct, overflow means we "failed" (but not critically). And when we do,
it's just remnants that need to be zero'd; so likely to be small.

> 
> > 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.

Agreed.

-- Steve