All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk 16/18] printk: Use struct cons_text_buf
Date: Mon, 10 Oct 2022 12:11:33 +0200	[thread overview]
Message-ID: <Y0Pv1Uwm6POpKEIY@alley> (raw)
In-Reply-To: <20220924000454.3319186-17-john.ogness@linutronix.de>

On Sat 2022-09-24 02:10:52, John Ogness wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Replace the separately allocated output buffers with a single instance of
> struct cons_text_buf.
> 
> Note that the buffer size of devkmsg_user.text_buf, when replaced with
> cons_text_buf.text, reduces from CONSOLE_EXT_LOG_MAX to CONSOLE_LOG_MAX.
> However, the buffer is only used to read ringbuffer records, which have
> a maximum size of LOG_LINE_MAX (CONSOLE_LOG_MAX - PREFIX_MAX).
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> ---
>  kernel/printk/printk.c | 50 ++++++++++++++++++------------------------
>  1 file changed, 21 insertions(+), 29 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 65e9903d066f..9cbd44e9fc45 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -671,11 +671,9 @@ struct devkmsg_user {
>  	atomic64_t seq;
>  	struct ratelimit_state rs;
>  	struct mutex lock;
> -	char buf[CONSOLE_EXT_LOG_MAX];
> -
>  	struct printk_info info;
> -	char text_buf[CONSOLE_EXT_LOG_MAX];
>  	struct printk_record record;
> +	struct cons_text_buf txtbuf;

I think about how to make it more clear that @txtbuf is not a simple
text buffer. It would help to better follow the code.

What about renaming "struct cons_text_buf", for example:

	struct con_text_bufs;
	struct con_bufs;
	struct console_text_buffers;
	struct console_buffers;

and use the variables, for example:

	ctbufs, cbufs, ct_bufs, c_bufs, con_bufs

>  };
>  
>  static __printf(3, 4) __cold
> @@ -758,6 +756,8 @@ static ssize_t devkmsg_read(struct file *file, char __user *buf,
>  {
>  	struct devkmsg_user *user = file->private_data;
>  	struct printk_record *r = &user->record;
> +	char *outbuf = user->txtbuf.ext_text;

Please, use either "ext_text" or "ext_text_buf". 

> +	const int maxlen = sizeof(user->txtbuf.ext_text);

and "ext_text_size" or "ext_text_buf_size"

to follow the existing style, for example:

	info_print_ext_header(buf, size, info).
	prb_rec_init_rd(r, info, text_buf, text_buf_size).

>  	size_t len;
>  	ssize_t ret;
>  
> @@ -2741,13 +2742,13 @@ static bool console_emit_next_record(struct console *con, char *text, char *ext_
>  		goto skip;
>  	}
>  
> -	if (ext_text) {
> -		write_text = ext_text;
> -		len = info_print_ext_header(ext_text, CONSOLE_EXT_LOG_MAX, r.info);
> -		len += msg_print_ext_body(ext_text + len, CONSOLE_EXT_LOG_MAX - len,
> +	if (extmsg) {

We could get this from the console flags:

	if (con->flags & CON_EXTENDED) {

> +		write_text = txtbuf->ext_text;
> +		len = info_print_ext_header(write_text, CONSOLE_EXT_LOG_MAX, r.info);
> +		len += msg_print_ext_body(write_text + len, CONSOLE_EXT_LOG_MAX - len,
>  					  &r.text_buf[0], r.info->text_len, &r.info->dev_info);

I would use this opportunity and get rid of the hardcoded *_LOG_MAX
lengts and something like:

		write_text = txtbuf->ext_text;
		write_text_size = sizeof(txtbuf->ext_text);
		len = info_print_ext_header(write_text, write_text_size, r.info);
		len += msg_print_ext_body(write_text + len, write_text_size - len,
					  &r.text_buf[0], r.info->text_len, &r.info->dev_info);


Using the hard coded size is error prone. It makes the review
complicated especially when we are going to pass the buffers
via some structures or generic pointers. I always have to check
if it is still the same buffer.

The only sane way is to use either sizeof(buf) or pass/store
@buf_size.


In addition, I would set here:

		dropped_text = txtbuf->ext_text;
		dropped_text_size = sizeof(txtbuf->ext_text);

As a result, we could define as:

struct con_text_bufs {
	char	ext_text[CONSOLE_EXT_LOG_MAX];
	char	text[CONSOLE_LOG_MAX];
} __no_randomize_layout;

and remove DROPPED_TEXT_MAX. I see that it is actually done later
anyway. Adding the union is just a temporary twist that complicates
the review.

>  	} else {
> -		write_text = text;
> +		write_text = txtbuf->text;
>  		len = record_print_text(&r, console_msg_format & MSG_FORMAT_SYSLOG, printk_time);

		write_text = txtbuf->text;
		write_text_size = sizeof(txtbuf->text);
		len = record_print_text(&r, console_msg_format & MSG_FORMAT_SYSLOG, printk_time);

		dropped_text = NULL;
		dropped_text_size = 0;

>  	}
>  
> @@ -2765,7 +2766,7 @@ static bool console_emit_next_record(struct console *con, char *text, char *ext_
>  	console_lock_spinning_enable();
>  
>  	stop_critical_timings();	/* don't trace print latency */
> -	call_console_driver(con, write_text, len, dropped_text);
> +	call_console_driver(con, write_text, len, extmsg ? NULL : txtbuf->dropped_text);

	call_console_driver(con, write_text, len, dropped_text, dropped_text_size);

>  	start_critical_timings();
>  
>  	con->seq++;

Best Regards,
Petr

  parent reply	other threads:[~2022-10-10 10:11 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-24  0:04 [PATCH printk 00/18] preparation for threaded/atomic printing John Ogness
2022-09-24  0:04 ` [PATCH printk 01/18] printk: Make pr_flush() static John Ogness
2022-09-26 14:12   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 02/18] printk: Declare log_wait properly John Ogness
2022-09-26 14:22   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 03/18] printk: Remove write only variable nr_ext_console_drivers John Ogness
2022-09-26 14:25   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 04/18] printk: Remove bogus comment vs. boot consoles John Ogness
2022-09-26 14:26   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 05/18] printk: Mark __printk percpu data ready __ro_after_init John Ogness
2022-09-26 14:27   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 06/18] printk: Protect [un]register_console() with a mutex John Ogness
2022-09-24  9:31   ` Sergey Senozhatsky
2022-09-27 15:16   ` Petr Mladek
2022-09-28  9:46     ` Sergey Senozhatsky
2022-09-28 23:42     ` John Ogness
2022-09-29 15:43       ` Petr Mladek
2022-09-30  9:24         ` Petr Mladek
2022-09-30 14:16           ` John Ogness
2022-09-30 18:04             ` Petr Mladek
2022-09-30 20:26               ` John Ogness
2022-10-03 14:37                 ` Petr Mladek
2022-10-03 19:35                   ` John Ogness
2022-10-04  2:06                     ` Sergey Senozhatsky
2022-10-04  7:28                     ` Petr Mladek
2022-09-30 13:30         ` John Ogness
2022-09-24  0:04 ` [PATCH printk 07/18] printk: Convert console list walks for readers to list lock John Ogness
2022-09-27 14:07   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 08/18] parisc: Put console abuse into one place John Ogness
2022-09-24  0:20   ` Steven Rostedt
2022-09-30  7:54   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 09/18] serial: kgdboc: Lock console list in probe function John Ogness
2022-09-28 23:32   ` Doug Anderson
2022-09-30  8:07   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 10/18] kgbd: Pretend that console list walk is safe John Ogness
2022-09-26  9:33   ` Aaron Tomlin
2022-09-28 23:32   ` Doug Anderson
2022-09-30  8:39     ` Petr Mladek
2022-09-30 13:44       ` John Ogness
2022-09-30 17:27         ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 11/18] printk: Convert console_drivers list to hlist John Ogness
2022-09-24 10:53   ` Sergey Senozhatsky
2022-09-24 17:20   ` Helge Deller
2022-09-25  0:43     ` Sergey Senozhatsky
2022-09-24 17:27   ` Helge Deller
2022-09-25  4:33   ` kernel test robot
2022-09-30 14:20   ` Petr Mladek
2022-09-30 16:53     ` Helge Deller
2022-09-30 19:46       ` John Ogness
2022-09-30 22:41         ` Helge Deller
2022-09-24  0:04 ` [PATCH printk 12/18] printk: Prepare for SCRU console list protection John Ogness
2022-09-24 10:58   ` Sergey Senozhatsky
2022-09-24  0:04 ` [PATCH printk 13/18] printk: Move buffer size defines John Ogness
2022-09-24 11:01   ` Sergey Senozhatsky
2022-10-07  9:11   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 14/18] printk: Document struct console John Ogness
2022-09-24 11:08   ` Sergey Senozhatsky
2022-10-07 11:57   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 15/18] printk: Add struct cons_text_buf John Ogness
2022-09-24 11:09   ` Sergey Senozhatsky
2022-10-07 15:15   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 16/18] printk: Use " John Ogness
2022-09-24 11:34   ` Sergey Senozhatsky
2022-10-10 10:11   ` Petr Mladek [this message]
2022-09-24  0:04 ` [PATCH printk 17/18] printk: Use an output descriptor struct for emit John Ogness
2022-10-10 15:40   ` Petr Mladek
2022-09-24  0:04 ` [PATCH printk 18/18] printk: Handle dropped message smarter John Ogness
2022-09-26  4:19   ` Sergey Senozhatsky
2022-09-26  7:54     ` John Ogness
2022-09-26  9:18       ` Sergey Senozhatsky
2022-10-10 16:07       ` Petr Mladek
2022-09-26  9:22   ` Sergey Senozhatsky
2022-09-24  6:44 ` [PATCH printk 00/18] preparation for threaded/atomic printing Greg Kroah-Hartman
2022-09-25 15:23   ` John Ogness
2022-09-24  9:47 ` Sergey Senozhatsky
2022-09-29 16:33 ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0Pv1Uwm6POpKEIY@alley \
    --to=pmladek@suse.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.