linux-kernel - Re: [PATCH printk v1 07/13] printk: move buffer definitions into console_emit_next

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: <Yg0iA/McHYWK6d4D@alley>
Date:   Wed, 16 Feb 2022 17:10:43 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v1 07/13] printk: move buffer definitions into
 console_emit_next_record() caller

On Mon 2022-02-07 20:49:17, John Ogness wrote:
> Extended consoles print extended messages and do not print messages about
> dropped records.
> 
> Non-extended consoles print "normal" messages as well as extra messages
> about dropped records.
> 
> Currently the buffers for these various message types are defined within
> the functions that might use them and their usage is based upon the
> CON_EXTENDED flag. This will be a problem when moving to kthread printers
> because each printer must be able to provide its own buffers.
> 
> Move all the message buffer definitions outside of
> console_emit_next_record(). The caller knows if extended or dropped
> messages should be printed and can specify the appropriate buffers to
> use. The console_emit_next_record() and call_console_driver() functions
> can know what to print based on whether specified buffers are non-NULL.
> 
> With this change, buffer definition/allocation/specification is separated
> from the code that does the various types of string printing.
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 822b7b6ad6d1..02bde45c1149 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2597,13 +2611,13 @@ static bool console_emit_next_record(struct console *con, bool *handover)
>  		goto skip;
>  	}
>  
> -	if (con->flags & CON_EXTENDED) {
> -		write_text = &ext_text[0];
> -		len = info_print_ext_header(ext_text, sizeof(ext_text), r.info);
> -		len += msg_print_ext_body(ext_text + len, sizeof(ext_text) - len,
> +	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,
>  					  &r.text_buf[0], r.info->text_len, &r.info->dev_info);
>  	} else {
> -		write_text = &text[0];
> +		write_text = text;
>  		len = record_print_text(&r, console_msg_format & MSG_FORMAT_SYSLOG, printk_time);

@text and @ext_text buffers are never used at the same time. It might
be enough to use a single text[CONSOLE_EXT_LOG_MAX] buffer. It would
even slightly simplify the code.

>  	}
>  
> @@ -2621,7 +2635,7 @@ static bool console_emit_next_record(struct console *con, bool *handover)
>  	console_lock_spinning_enable();
>  
>  	stop_critical_timings();	/* don't trace print latency */
> -	call_console_driver(con, write_text, len);
> +	call_console_driver(con, write_text, len, dropped_text);
>  	start_critical_timings();
>  
>  	con->seq++;
> @@ -2650,6 +2664,9 @@ static bool console_emit_next_record(struct console *con, bool *handover)
>   */
>  static bool console_flush_all(bool do_cond_resched, u64 *next_seq, bool *handover)
>  {
> +	static char dropped_text[DROPPED_TEXT_MAX];
> +	static char ext_text[CONSOLE_EXT_LOG_MAX];
> +	static char text[CONSOLE_LOG_MAX];

These buffers are for printing from console_unlock(). The same buffers
will need to be allocated for each console in the kthreads.

It might make sense to allocate these buffers in register_console()
and store the pointers in struct console.

Well, we might need extra buffers for atomic console drivers and
diffent contexts that would be used during panic. But maybe
they can be allocated in register_console() as well.



>  	bool any_usable = false;
>  	struct console *con;
>  	bool any_progress;
> @@ -2667,7 +2684,16 @@ static bool console_flush_all(bool do_cond_resched, u64 *next_seq, bool *handove
>  				continue;
>  			any_usable = true;
>  
> -			progress = console_emit_next_record(con, handover);
> +			if (con->flags & CON_EXTENDED) {
> +				/* Extended consoles do not print "dropped messages". */
> +				progress = console_emit_next_record(con, &text[0],

IMHO, &text[0] buffer is not used for extended consoles.

> +								    &ext_text[0], NULL,
> +								    handover);
> +			} else {
> +				progress = console_emit_next_record(con, &text[0],
> +								    NULL, &dropped_text[0],
> +								    handover);
> +			}
>  			if (*handover)
>  				return true;

I do not resist on allocating the buffers in register_console(). I am
not sure if it would really makes things easier.

But I would really like to use the same buffer for normal and extended
consoles if possible.

Best Regards,
Petr