All of lore.kernel.org
 help / color / mirror / Atom feed
From: "\"Jan H. Schönherr\"" <schnhrr@cs.tu-berlin.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, Kay Sievers <kay@vrfy.org>
Subject: Re: [PATCH resend] printk: drop ambiguous LOG_CONT flag
Date: Sat, 10 Nov 2012 19:47:05 +0100	[thread overview]
Message-ID: <509EA129.800@cs.tu-berlin.de> (raw)
In-Reply-To: <1351977176-28381-1-git-send-email-schnhrr@cs.tu-berlin.de>

Hi Greg.

This still needs a small fix, see below.

Am 03.11.2012 22:12, schrieb Jan H. Schönherr:
> From: Jan H. Schönherr <schnhrr@cs.tu-berlin.de>
> 
> The meaning of LOG_CONT is unclear, i. e., whether a message is a starting,
> ending, or middle fragment. Unfortunately, this cannot be inferred from
> the LOG_PREFIX and LOG_NEWLINE flags, as they are not always kept.
> Furthermore, in some cases LOG_CONT is set, although it is unknown if
> there will be a continuation. This leads to wrongly concatenated output.
> 
> Fix this by dropping LOG_CONT and rely on LOG_PREFIX and LOG_NEWLINE to
> distinguish the type of fragment. That is, if LOG_PREFIX is set, this
> fragment does not continue the previous fragment. And if LOG_NEWLINE is
> set, this fragment is not continued by the next fragment.
> 
> (Unfortunately, we still have to look at the previous fragment to catch the
> case of an unset LOG_PREFIX on this fragment, but a set LOG_NEWLINE on
> the previous fragment.)
> 
> Tested-By: Kay Sievers <kay@vrfy.org>
> Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de>
> ---
> Against linux-next from 20121102, added Kay's tested-by.
> ---
>  kernel/printk.c | 57 +++++++++++++++++++++++++++++++++------------------------
>  1 file changed, 33 insertions(+), 24 deletions(-)
> 
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 22e070f..e8e4e67 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c

[...]

> @@ -1581,12 +1585,16 @@ asmlinkage int vprintk_emit(int facility, int level,
>  		 * Flush the conflicting buffer. An earlier newline was missing,
>  		 * or another task also prints continuation lines.
>  		 */
> -		if (cont.len && (lflags & LOG_PREFIX || cont.owner != current))
> -			cont_flush(LOG_NEWLINE);
> +		if (cont.len) {

This line should have been:
+		if (cont.len && !cont.flushed) {

The effect of this is that we now avoid to add a superfluous newline
over and over (due to setting LOG_PREFIX), when the cont buffer has been
flushed but not yet printed.

> +			if (cont.owner != current)
> +				lflags |= LOG_PREFIX;
> +			if (lflags & LOG_PREFIX)
> +				cont_flush(LOG_NEWLINE);
> +		}
>  
>  		/* buffer line if possible, otherwise store it right away */
> -		if (!cont_add(facility, level, text, text_len))
> -			log_store(facility, level, lflags | LOG_CONT, 0,
> +		if (!cont_add(facility, level, lflags, text, text_len))
> +			log_store(facility, level, lflags, 0,
>  				  dict, dictlen, text, text_len);
>  	} else {
>  		bool stored = false;
> @@ -1599,7 +1607,8 @@ asmlinkage int vprintk_emit(int facility, int level,
>  		 */
>  		if (cont.len && cont.owner == current) {

For symmetry reasons, the "if" here could use the same change. But here it
does not really matter as currently cont_add() and cont_flush() are NOPs when
cont.flushed is set.

>  			if (!(lflags & LOG_PREFIX))
> -				stored = cont_add(facility, level, text, text_len);
> +				stored = cont_add(facility, level, lflags,
> +							text, text_len);
>  			cont_flush(LOG_NEWLINE);
>  		}

As I've not yet seen this patch turn up anywhere, I'm preparing a v2 of this
together with a couple of other patches that are now more or less ready.

Regards
Jan



  reply	other threads:[~2012-11-10 18:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-26 17:58 [PATCH] printk: drop ambiguous LOG_CONT flag Jan H. Schönherr
2012-09-26 21:15 ` Greg Kroah-Hartman
2012-09-26 22:33   ` "Jan H. Schönherr"
2012-09-27 13:39     ` Kay Sievers
2012-09-27 15:46       ` "Jan H. Schönherr"
2012-09-27 16:04         ` "Jan H. Schönherr"
2012-09-28  8:25           ` Jan H. Schönherr
2012-09-28 14:34             ` Kay Sievers
2012-09-28 14:49               ` "Jan H. Schönherr"
2012-09-28 14:56                 ` Kay Sievers
2012-10-08 19:24                   ` Kay Sievers
2012-10-08 19:54                     ` "Jan H. Schönherr"
2012-10-08 19:56                       ` Kay Sievers
2012-11-02  3:53                         ` Kay Sievers
2012-11-02 22:37                           ` "Jan H. Schönherr"
2012-11-02 23:36                             ` Greg Kroah-Hartman
2012-11-03 21:12                               ` [PATCH resend] " Jan H. Schönherr
2012-11-10 18:47                                 ` "Jan H. Schönherr" [this message]
2012-10-08 23:10                       ` [PATCH] " Joe Perches
2012-09-28  2:28         ` Kay Sievers

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=509EA129.800@cs.tu-berlin.de \
    --to=schnhrr@cs.tu-berlin.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=kay@vrfy.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 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.