public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Petr Mládek" <pmladek@suse.cz>
To: Alex Elder <elder@linaro.org>
Cc: akpm@linux-foundation.org, bp@suse.de, john.stultz@linaro.org,
	jack@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] printk: honor LOG_PREFIX in msg_print_text()
Date: Thu, 17 Jul 2014 11:40:42 +0200	[thread overview]
Message-ID: <20140717094031.GQ6774@pathway.suse.cz> (raw)
In-Reply-To: <1405531620-9983-4-git-send-email-elder@linaro.org>

On Wed 2014-07-16 12:26:59, Alex Elder wrote:
> This patch fixes a problem similar to what was addressed in the
> previous patch.
> 
> All paths that read and format log records (for consoles, and for
> reading via syslog and /dev/kmsg) go through msg_print_text().  That
> function starts with some logic to determine whether the given log
> record when formatted should begin with a "prefix" string, and
> whether it should end with a newline.  That logic has a bug.
> 
> The LOG_PREFIX flag in a log record indicates that when it's
> formatted, a log record should include a prefix.  This is used to
> force a record to begin a new line--even if its preceding log record
> contained LOG_CONT (indicating its content should be combined with
> the next record).
> 
> Like the previous patch, the problem occurs when these flags are
> all set:
>     prev & LOG_CONT
>     msg->flags & LOG_PREFIX
>     msg->flags & LOG_CONT
> In that case, "prefix" should be true but it is not.

You are right.

> The fix involves checking LOG_PREFIX when a message has its LOG_CONT
> flag set, and in that case allowing "prefix" to become false only
> if LOG_PREFIX is not set.  I.e., the logic for "prefix" would become:
> 
>     if (prev & LOG_CONT && !(msg->flags & LOG_PREFIX))
>         prefix = false;
>     if (msg->flags & LOG_CONT)
>         if (prev & LOG_CONT && !(msg->flags & LOG_PREFIX))
>             prefix = false;
> 
> However, note that this makes the (msg->flags & LOG_CONT) block
> redunant--it's handled by the test just above it.  The result
> becomes quite a bit simpler than before.
> 
> The following table concisely defines the problem:
> 
>      prev | msg  | msg  ||
>      CONT |PREFIX| CONT ||prefix
>     ------+------+------++------
>      clear| clear| clear|| true
>      clear| clear|  set || true
>      clear|  set | clear|| true
>      clear|  set |  set || true
>       set | clear| clear||false
>       set |  set |  set ||false
>       set |  set | clear|| true
>       set |  set |  set ||false      <-- should be true
> 
> Signed-off-by: Alex Elder <elder@linaro.org>
> ---
>  kernel/printk/printk.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 9e9cf93..3f15d95 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1003,14 +1003,11 @@ static size_t msg_print_text(const struct printk_log *msg, enum log_flags prev,
>  	bool newline = true;
>  	size_t len = 0;
>  
> -	if ((prev & LOG_CONT) && !(msg->flags & LOG_PREFIX))
> +	if (prev & LOG_CONT && !(msg->flags & LOG_PREFIX))
>  		prefix = false;

I would personaly keep the brackets there. For me.

  ( & ) && !( & )

is easier to parse than

  & && !( & )

> -	if (msg->flags & LOG_CONT) {
> -		if (prev & LOG_CONT)
> -			prefix = false;
> +	if (msg->flags & LOG_CONT)
>  		newline = false;
> -	}

You are right. The check before "prefix = false" did not make much
sense. We should not remove prefix just because the previous line was
continuous. Also it does not make sense to do this only when the new line
is continuous.

But I think that the fix is not complete. IMHO, we should finish the
previous continuous line with '\n' before we print the prefix. I mean something
like:

if ((prev & LOG_CONT) && (msg->flags & LOG_PREFIX) && (len < size)) {
	/* finish the incomplete continuous line */
	if (buf) {
		buf[len++] = '\n';
	} else {
		len++;
	}
}

Best Regards,
Petr


>  
>  	do {
>  		const char *next = memchr(text, '\n', text_size);
> -- 
> 1.9.1
> 

  reply	other threads:[~2014-07-17  9:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 17:26 [PATCH 0/4] printk: start simplifying some flags Alex Elder
2014-07-16 17:26 ` [PATCH 1/4] printk: LOG_CONT and LOG_NEWLINE are separate Alex Elder
2014-07-17  8:39   ` Petr Mládek
2014-07-17 12:11     ` Alex Elder
2014-07-17 14:46       ` Petr Mládek
2014-07-17 16:19         ` Alex Elder
2014-07-18  8:49           ` Petr Mládek
2014-07-17 12:31     ` Alex Elder
2014-07-16 17:26 ` [PATCH 2/4] printk: honor LOG_PREFIX in devkmsg_read() Alex Elder
2014-07-17 10:14   ` Petr Mládek
2014-07-17 12:19     ` Alex Elder
2014-07-16 17:26 ` [PATCH 3/4] printk: honor LOG_PREFIX in msg_print_text() Alex Elder
2014-07-17  9:40   ` Petr Mládek [this message]
2014-07-17 12:18     ` Alex Elder
2014-07-17 13:42       ` Alex Elder
2014-07-16 17:27 ` [PATCH 4/4] printk: correct some more typos Alex Elder
2014-07-17 11:46   ` Petr Mládek
2014-07-17 12:22     ` Alex Elder
2014-07-16 17:55 ` [PATCH 0/4] printk: start simplifying some flags Joe Perches

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=20140717094031.GQ6774@pathway.suse.cz \
    --to=pmladek@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=elder@linaro.org \
    --cc=jack@suse.cz \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox