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: <ZDVPJnx9tjetdm9K@alley>
Date:   Tue, 11 Apr 2023 14:14:30 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     Steven Rostedt <rostedt@...dmis.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 2023-04-11 11:55:56, Sergey Senozhatsky wrote:
> Sometimes we use seq_buf to format a string buffer, which
> we then pass to printk(). However, in certain situations
> the seq_buf string buffer can get too big, exceeding the
> PRINTKRB_RECORD_MAX bytes limit, and causing printk() to
> truncate the string.
> 
> Add a new seq_buf helper. This helper prints the seq_buf
> string buffer line by line, using \n as a delimiter,
> rather than passing the whole string buffer to printk()
> at once.
> 
> Signed-off-by: Sergey Senozhatsky <senozhatsky@...omium.org>
> ---
>  include/linux/seq_buf.h |  2 ++
>  lib/seq_buf.c           | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 32 insertions(+)
> 
> 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.


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

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