All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Joe Perches <joe@perches.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Petr Mladek <pmladek@suse.com>,
	Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jiri Slaby <jslaby@suse.com>, Andreas Mohr <andi@lisas.de>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: printk: what is going on with additional newlines?
Date: Mon, 4 Sep 2017 14:22:46 +0900	[thread overview]
Message-ID: <20170904052246.GB28534@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <CA+55aFxmL4ybpz19OPn97VYqAk2ZS-tf=0W2Ff1K=-UUB6mYyg@mail.gmail.com>

Hello,

I'll answer to both Linus and Joe, just to keep it all one place.

On (09/01/17 13:21), Linus Torvalds wrote:
> On Fri, Sep 1, 2017 at 10:32 AM, Joe Perches <joe@perches.com> wrote:
> >
> > Yes, it's a poor name.  At least keep using a pr_ prefix.
> 
> I'd suggest perhaps just "pr_line()".

ok, pr_line sound good.

> And instead of having those "err/info/cont" variations, the severity
> level should just be set at initialization time.  Not different
> versions of "pr_line()".
> 
> There's no point to having different severity variations, since the
> *only* reason for this would be for buffering. So "pr_cont()" is kind
> of assumed for everything but the first.
> 
> And even if you end up doing multiple lines, if you actually do
> different severities, you damn well shouldn't buffer them together.
> They are clearly different things!

hm... may be.
the main point of prbuf is not the support of cont lines, but the
fact that buffered messages are added to the logbuf atomically,
and thus are printed in consequent lines, not the usual way:

CPU0	because
CPU1	this
CPU0	it's easier
CPU1	might
CPU0	to read
CPU1	be
CPU1	inconvenient.
CPU0	seq messages.

some people want to be able to make it to look less spaghetti-like:

CPU0	because
CPU0	it's easier
CPU0	to read
CPU0	seq messages.
CPU1	this
CPU1	might
CPU1	be
CPU1	inconvenient.

and it's not something completely wrong to ask for, I think.
well, who knows.

there is only way to serialize printks against other printks -- take
the logbuf lock. and that's what pr_line/prbuf flush is doing.


now, pr_line/prbuf/pr_buf is, of course, very limited. it should NOT
be used for things that are really important and absolutely must [if
possible] appear in serial logs/on screens/etc. simply because panic
can happen on CPUA before we flush any pending pr_line/prbuf buffers
on other CPUs. and that's exactly the reason why I initially wanted
(and still do) to implement pr_line/prbuf using printk-safe
mechanism - because we flush printk-safe buffers from panic(). so
utilizing printk-safe buffers can make pr_line less fragile. apart
from that printk-safe buffers are always there, so OOM is not a show
stopper anymore. but, like I said in another email, printk-safe buffer
is per-CPU and is also used for actual printk-safe, hence it must be
used with local IRQs disabled when we "borrow" the buffer for pr_line
(disabled preemption is not enough due to possible IRQ printk-safe
print out). this can be a bit annoying.

in it's current form, pr_line/pr_buf is NOT a replacement for pr_cont
or printk(KERN_CONT). because pr_cont has no such thing as "we were
unable to flush the buffer from CPUB because of panic on CPUA". so
pr_cont/printk(KERN_CONT) beats pr_line/pr_buf here. This can be a
major limitation. am I wrong?


another thing,
if we eventually will decide to stick to "use a seq_buf with stack
allocated char buffer to hold a single line only" design, then I'm
not entirely sure I get it why do we want to add a new API at all.
I mean, the new API does not make anything simpler or shorter. we
need to declare the buffer, seq_buf, init seq_buf, append chars to
seq_buf, flush it:

	char buf[80];
	struct seq_buf cont_line;

	pr_line_init(&cont_line, buf, sizeof(buf));
	pr_line_printf(&cont_line, "....");
	pr_line_printf(&cont_line, "....");
	pr_line_flush(&cont_line);

this asks for  s/pr_line_/seq_buf_/g, no? well, except for the flush()
part. it can be replaced with printk("%s\n", cont_line->buffer).

so it seems that we need to re-think it.

	-ss

  reply	other threads:[~2017-09-04  5:25 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-15  2:56 [RFC][PATCHv5 00/13] printk: introduce printing kernel thread Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 01/13] printk: move printk_pending out of per-cpu Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 02/13] printk: introduce printing kernel thread Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 03/13] printk: add sync printk_emergency API Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 04/13] printk: add enforce_emergency parameter Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 05/13] printk: enable printk offloading Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 06/13] printk: register PM notifier Sergey Senozhatsky
2017-08-15 11:51   ` Rafael J. Wysocki
2017-08-16  7:31     ` Sergey Senozhatsky
2017-08-16 12:58       ` Rafael J. Wysocki
2017-08-17  5:55         ` Sergey Senozhatsky
2017-08-17 15:43           ` Rafael J. Wysocki
2017-08-17 23:19             ` Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 07/13] printk: register syscore notifier Sergey Senozhatsky
2017-08-15 11:56   ` Rafael J. Wysocki
2017-08-16  6:55     ` Sergey Senozhatsky
2017-08-16 12:59       ` Rafael J. Wysocki
2017-08-15  2:56 ` [RFC][PATCHv5 08/13] printk: set watchdog_thresh as maximum value for atomic_print_limit Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 09/13] printk: add auto-emergency enforcement mechanism Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 10/13] printk: force printk_kthread to offload printing Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 11/13] printk: always offload printing from user-space processes Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 12/13] printk: do not cond_resched() when we can offload Sergey Senozhatsky
2017-08-15  2:56 ` [RFC][PATCHv5 13/13] printk: move offloading logic to per-cpu Sergey Senozhatsky
2017-08-23  8:33 ` [RFC][PATCHv5 00/13] printk: introduce printing kernel thread Sergey Senozhatsky
2017-08-28  9:05 ` printk: what is going on with additional newlines? Pavel Machek
2017-08-28 10:28   ` Sergey Senozhatsky
2017-08-28 12:21     ` Sergey Senozhatsky
2017-08-28 12:38       ` Sergey Senozhatsky
2017-08-28 12:46       ` Pavel Machek
2017-08-29 13:40         ` Sergey Senozhatsky
2017-08-29 16:37           ` Joe Perches
2017-08-29 17:00           ` Linus Torvalds
2017-08-29 17:12             ` Linus Torvalds
2017-08-29 20:41               ` Tetsuo Handa
2017-08-29 20:51                 ` Linus Torvalds
2017-09-02  6:12                   ` Tetsuo Handa
2017-09-02 17:06                     ` Linus Torvalds
2017-08-29 23:50               ` Steven Rostedt
2017-08-29 23:59                 ` Linus Torvalds
2017-08-30  1:03                 ` Sergey Senozhatsky
2017-08-30  1:10                   ` Steven Rostedt
2017-08-30  1:51                     ` Sergey Senozhatsky
2017-08-30  1:52                     ` Joe Perches
2017-08-30  2:25                       ` Sergey Senozhatsky
2017-08-30  2:31                         ` Joe Perches
2017-08-30  2:47                           ` Sergey Senozhatsky
2017-08-30  2:58                             ` Joe Perches
2017-08-30  5:37                               ` Sergey Senozhatsky
2017-09-08 10:18                                 ` Pavel Machek
2017-09-05  9:44                             ` Petr Mladek
2017-09-05  9:59                               ` Sergey Senozhatsky
2017-09-05 12:21                                 ` Petr Mladek
2017-09-05 12:35                                   ` Tetsuo Handa
2017-09-05 14:18                                     ` Sergey Senozhatsky
2017-09-05 13:42                                   ` Sergey Senozhatsky
2017-09-06  7:55                                     ` Petr Mladek
2017-09-17  6:26                                       ` Sergey Senozhatsky
2017-09-17  9:27                                         ` Sergey Senozhatsky
2017-09-17 15:35                                         ` Linus Torvalds
2017-09-18  0:46                                           ` Sergey Senozhatsky
2017-09-18  2:22                                             ` Joe Perches
2017-09-18  2:41                                               ` Sergey Senozhatsky
2017-09-18  2:45                                                 ` Joe Perches
2017-09-18  2:55                                                   ` Sergey Senozhatsky
2017-09-18  3:07                                                     ` Joe Perches
2017-09-18  4:42                                                       ` Sergey Senozhatsky
2017-09-01 13:19                     ` Sergey Senozhatsky
2017-09-01 17:32                       ` Joe Perches
2017-09-01 20:21                         ` Linus Torvalds
2017-09-04  5:22                           ` Sergey Senozhatsky [this message]
2017-09-04  5:41                             ` Joe Perches
2017-09-05 14:54                             ` Steven Rostedt
2017-09-06  2:14                               ` Sergey Senozhatsky
2017-09-06  2:36                               ` Linus Torvalds
2017-09-04  4:30                         ` Sergey Senozhatsky
2017-09-04  5:24                           ` Sergey Senozhatsky
2017-08-29 17:33             ` Sergey Senozhatsky
2017-08-29 17:52               ` Linus Torvalds
2017-08-29 18:09                 ` Joe Perches
2017-08-30  1:07                   ` Sergey Senozhatsky
2017-08-30  0:58                 ` Sergey Senozhatsky
2017-08-29 16:48   ` Linus Torvalds
2017-08-29 17:10     ` Joe Perches
2017-08-29 17:20       ` Linus Torvalds
2017-08-29 17:33         ` Joe Perches
2017-08-29 17:36           ` Linus Torvalds
2017-08-29 17:48             ` Joe Perches
2017-08-29 20:24     ` Pavel Machek
2017-09-01  1:40       ` Sergey Senozhatsky
2017-09-01  2:04         ` Joe Perches
2017-09-01  6:59           ` Pavel Machek
2017-09-01  7:23             ` Joe Perches
2017-09-01  7:29         ` Pavel Machek
2017-09-01 11:13           ` Steven Rostedt

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=20170904052246.GB28534@jagdpanzerIV.localdomain \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@lisas.de \
    --cc=jack@suse.cz \
    --cc=joe@perches.com \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=torvalds@linux-foundation.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.