linux-kernel - Re: [PATCH] seq_buf: add seq_buf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230411101033.1868494e@gandalf.local.home>
Date:   Tue, 11 Apr 2023 10:10:33 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yosry Ahmed <yosryahmed@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] seq_buf: add seq_buf_printk() helper

On Tue, 11 Apr 2023 14:14:30 +0200
Petr Mladek <pmladek@...e.com> wrote:

> > diff --git a/include/linux/seq_buf.h b/include/linux/seq_buf.h
> > index 5b31c5147969..80b78df89809 100644
> > --- a/include/linux/seq_buf.h
> > +++ b/include/linux/seq_buf.h
> > @@ -159,4 +159,6 @@ extern int
> >  seq_buf_bprintf(struct seq_buf *s, const char *fmt, const u32 *binary);
> >  #endif
> >  
> > +void seq_buf_printk(struct seq_buf *s, const char *lvl);
> > +
> >  #endif /* _LINUX_SEQ_BUF_H */
> > diff --git a/lib/seq_buf.c b/lib/seq_buf.c
> > index 0a68f7aa85d6..9d13004c2324 100644
> > --- a/lib/seq_buf.c
> > +++ b/lib/seq_buf.c
> > @@ -93,6 +93,36 @@ int seq_buf_printf(struct seq_buf *s, const char *fmt, ...)
> >  }
> >  EXPORT_SYMBOL_GPL(seq_buf_printf);
> >  
> > +/**
> > + * seq_buf_printk - printk seq_buf line by line
> > + * @s: seq_buf descriptor
> > + * @lvl: printk level
> > + *
> > + * printk()-s a multi-line sequential buffer line by line
> > + */
> > +void seq_buf_printk(struct seq_buf *s, const char *lvl)  
> 
> We might want to somehow distinguish that this is actually
> printing (reading) the context of the buffer.
> 
> The name is similar to seq_buf_printf() and seq_buf_vprintf()
> whose are wrinting into the buffer.
> 
> What about the following?
> 
>      + seq_buf_printf_seq() like the existing seq_buf_print_seq()
>      + seq_buf_to_printk() like the existing seq_buf_to_user()
> 
> I personally prefer seq_buf_to_printk() because it looks more
> selfexplaining to me.
> 
> Or maybe: seq_buf_to_printk_lvl() to allow later add
> seq_buf_to_printk() that would us the default loglevel.
> 

seq_buf came from trace_seq to become more generic. trace_seq is also part
of the libtraceevent library, and there we have:

  trace_seq_do_printf()

 https://www.trace-cmd.org/Documentation/libtraceevent/libtraceevent-tseq.html

That is to differentiate the trace_seq_printf() function. And does what
this function is doing (dumping the buffer).

Perhaps we should use the precedence of that function and have:

  seq_buf_do_printk()

> 
> > +{
> > +	const char *start, *lf;
> > +	int len;
> > +
> > +	if (s->size == 0)
> > +		return;
> > +
> > +	start = s->buffer;
> > +	while ((lf = strchr(start, '\n'))) {  
> 
> We should rather use strnchr(). It seems that the trailing '\0' is
> not guaranteed. For example, seq_buf_putc() just adds the given
> character at the end.

I think we should add a seq_buf_terminate() that adds the '\0' to the
buffer. There's one for user space (trace_seq_terminate()).

It's a nop if it already has the '\0'.

I think we should add that first, and then we can use that when entering
this function.

-- Steve

> 
> > +		len = lf - start + 1;
> > +		printk("%s%.*s", lvl, len, start);
> > +		start = ++lf;
> > +	}
> > +
> > +	/* No trailing LF */
> > +	if (start < s->buffer + s->len) {
> > +		len = s->buffer + s->len - start;
> > +		printk("%s%.*s\n", lvl, len, start);
> > +	}
> > +}
> > +EXPORT_SYMBOL_GPL(seq_buf_printk);  
> 
> Otherwise, it looks good to me.
> 
> Best Regards,
> Petr