* [PATCH] seq_buf: add seq_buf_printk() helper
@ 2023-04-11 2:55 Sergey Senozhatsky
2023-04-11 3:45 ` Yosry Ahmed
2023-04-11 12:14 ` Petr Mladek
0 siblings, 2 replies; 6+ messages in thread
From: Sergey Senozhatsky @ 2023-04-11 2:55 UTC (permalink / raw)
To: Steven Rostedt, Petr Mladek
Cc: Andrew Morton, Yosry Ahmed, linux-kernel, Sergey Senozhatsky
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@chromium.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)
+{
+ const char *start, *lf;
+ int len;
+
+ if (s->size == 0)
+ return;
+
+ start = s->buffer;
+ while ((lf = strchr(start, '\n'))) {
+ 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);
+
#ifdef CONFIG_BINARY_PRINTF
/**
* seq_buf_bprintf - Write the printf string from binary arguments
--
2.40.0.577.gac1e443424-goog
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] seq_buf: add seq_buf_printk() helper
2023-04-11 2:55 [PATCH] seq_buf: add seq_buf_printk() helper Sergey Senozhatsky
@ 2023-04-11 3:45 ` Yosry Ahmed
2023-04-11 12:14 ` Petr Mladek
1 sibling, 0 replies; 6+ messages in thread
From: Yosry Ahmed @ 2023-04-11 3:45 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Steven Rostedt, Petr Mladek, Andrew Morton, linux-kernel
On Mon, Apr 10, 2023 at 7:56 PM Sergey Senozhatsky
<senozhatsky@chromium.org> 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@chromium.org>
I tested this with a local patch that I am currently working on that
benefits from this helper, works great.
Tested-by: Yosry Ahmed <yosryahmed@google.com>
>
> ---
> 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)
> +{
> + const char *start, *lf;
> + int len;
> +
> + if (s->size == 0)
> + return;
> +
> + start = s->buffer;
> + while ((lf = strchr(start, '\n'))) {
> + 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);
> +
> #ifdef CONFIG_BINARY_PRINTF
> /**
> * seq_buf_bprintf - Write the printf string from binary arguments
> --
> 2.40.0.577.gac1e443424-goog
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] seq_buf: add seq_buf_printk() helper
2023-04-11 2:55 [PATCH] seq_buf: add seq_buf_printk() helper Sergey Senozhatsky
2023-04-11 3:45 ` Yosry Ahmed
@ 2023-04-11 12:14 ` Petr Mladek
2023-04-11 14:10 ` Steven Rostedt
2023-04-11 14:24 ` Sergey Senozhatsky
1 sibling, 2 replies; 6+ messages in thread
From: Petr Mladek @ 2023-04-11 12:14 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Steven Rostedt, Andrew Morton, Yosry Ahmed, linux-kernel
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@chromium.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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] seq_buf: add seq_buf_printk() helper
2023-04-11 12:14 ` Petr Mladek
@ 2023-04-11 14:10 ` Steven Rostedt
2023-04-11 14:27 ` Sergey Senozhatsky
2023-04-11 14:24 ` Sergey Senozhatsky
1 sibling, 1 reply; 6+ messages in thread
From: Steven Rostedt @ 2023-04-11 14:10 UTC (permalink / raw)
To: Petr Mladek; +Cc: Sergey Senozhatsky, Andrew Morton, Yosry Ahmed, linux-kernel
On Tue, 11 Apr 2023 14:14:30 +0200
Petr Mladek <pmladek@suse.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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] seq_buf: add seq_buf_printk() helper
2023-04-11 12:14 ` Petr Mladek
2023-04-11 14:10 ` Steven Rostedt
@ 2023-04-11 14:24 ` Sergey Senozhatsky
1 sibling, 0 replies; 6+ messages in thread
From: Sergey Senozhatsky @ 2023-04-11 14:24 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Steven Rostedt, Andrew Morton, Yosry Ahmed,
linux-kernel
On (23/04/11 14:14), Petr Mladek wrote:
> 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.
I like seq_buf_to_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.
Good point.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] seq_buf: add seq_buf_printk() helper
2023-04-11 14:10 ` Steven Rostedt
@ 2023-04-11 14:27 ` Sergey Senozhatsky
0 siblings, 0 replies; 6+ messages in thread
From: Sergey Senozhatsky @ 2023-04-11 14:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Sergey Senozhatsky, Andrew Morton, Yosry Ahmed,
linux-kernel
On (23/04/11 10:10), Steven Rostedt wrote:
[..]
> 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()
OK, I'll rename the helper to seq_buf_do_printk().
> > 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.
Sounds good. This also should address Petr's concern.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-11 14:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-11 2:55 [PATCH] seq_buf: add seq_buf_printk() helper Sergey Senozhatsky
2023-04-11 3:45 ` Yosry Ahmed
2023-04-11 12:14 ` Petr Mladek
2023-04-11 14:10 ` Steven Rostedt
2023-04-11 14:27 ` Sergey Senozhatsky
2023-04-11 14:24 ` Sergey Senozhatsky
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.