linux-kernel - Re: [PATCH v2 1/6] printk: initialize syslog_prev and console

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]

Date:	Fri, 18 Jul 2014 12:43:38 +0200
From:	Petr Mládek <pmladek@...e.cz>
To:	Alex Elder <elder@...aro.org>
Cc:	akpm@...ux-foundation.org, bp@...e.de, john.stultz@...aro.org,
	jack@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/6] printk: initialize syslog_prev and console_prev

On Thu 2014-07-17 09:09:06, Alex Elder wrote:
> Two global variables, "syslog_prev" and "console_prev", maintain a
> copy of the flags value used in the log record most recently
> formatted for syslog or the console, respectively.
> 
> Initially there is no previous formatted log record, and these
> variables simply have an initial value 0.  And occasionally log
> records can get consumed at a rate such that syslog or the console
> can't keep up, in which case those variables (along with their
> corresponding position variables) must be reset.  Here too, they're
> reset to 0.
> 
> This patch changes it so the initial value used is LOG_NEWLINE.
> That is, if we know nothing about the prevously-formatted log
> record, we can assume it was complete, and ended with a newline.
> 
> This is being done to support the next patch.  Initializing
> these variables this way makes LOG_NEWLINE and LOG_CONT be
> mutually exclusive, and the next patch uses that fact to simplify
> some logic.
> 
> Signed-off-by: Alex Elder <elder@...aro.org>
> ---
>  kernel/printk/printk.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 13e839d..ff1c7ad 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -236,7 +236,7 @@ DECLARE_WAIT_QUEUE_HEAD(log_wait);
>  /* the next printk record to read by syslog(READ) or /proc/kmsg */
>  static u64 syslog_seq;
>  static u32 syslog_idx;
> -static enum log_flags syslog_prev;
> +static enum log_flags syslog_prev = LOG_NEWLINE;
>  static size_t syslog_partial;
>  
>  /* index and sequence number of the first record stored in the buffer */
> @@ -250,7 +250,7 @@ static u32 log_next_idx;
>  /* the next printk record to write to the console */
>  static u64 console_seq;
>  static u32 console_idx;
> -static enum log_flags console_prev;
> +static enum log_flags console_prev = LOG_NEWLINE;

The above makes sense.

>  /* the next printk record to read after the last 'clear' command */
>  static u64 clear_seq;
> @@ -1071,7 +1071,7 @@ static int syslog_print(char __user *buf, int size)
>  			/* messages are gone, move to first one */
>  			syslog_seq = log_first_seq;
>  			syslog_idx = log_first_idx;
> -			syslog_prev = 0;
> +			syslog_prev = LOG_NEWLINE;
>  			syslog_partial = 0;
>  		}
>  		if (syslog_seq == log_next_seq) {
> @@ -1301,7 +1301,7 @@ int do_syslog(int type, char __user *buf, int len, bool from_file)
>  			/* messages are gone, move to first one */
>  			syslog_seq = log_first_seq;
>  			syslog_idx = log_first_idx;
> -			syslog_prev = 0;
> +			syslog_prev = LOG_NEWLINE;
>  			syslog_partial = 0;
>  		}
>  		if (from_file) {
> @@ -2148,7 +2148,7 @@ again:
>  			/* messages are gone, move to first one */
>  			console_seq = log_first_seq;
>  			console_idx = log_first_idx;
> -			console_prev = 0;
> +			console_prev = LOG_NEWLINE;
>  		} else {
>  			len = 0;
>  		}

It would make sense to add '\n' if we skip something and the previous
copied line was continuous. This would change the behavior, so we
should do this in separate patch.

Anyway, it makes sense to reset the flag to LOG_NEWLINE.

Reviewed-by: Petr Mladek <pmladek@...e.cz>

> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/