From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Joe Perches <joe@perches.com>,
Sergey Senozhatsky <sergey.senozhatsky@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: Wed, 6 Sep 2017 11:14:26 +0900 [thread overview]
Message-ID: <20170906021426.GA6773@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <20170905105454.29160c5e@gandalf.local.home>
On (09/05/17 10:54), Steven Rostedt wrote:
> On Mon, 4 Sep 2017 14:22:46 +0900
> Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
>
> > 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.
>
> You can do what I did with trace_printk(). I have a buffer per context.
> Then you only need to use preempt_disable() to do the print. That is,
> trace_printk() has 4 buffers:
>
> 1. Normal context
> 2. softirq context
> 3. irq context
> 4. NMI context
thanks. looks interesting.
> It determines which context it is in, disables preemption, and uses the
> corresponding buffer. This way I don't need to worry about being
> preempted by an interrupt or NMI.
>
> Grant it, it does make the memory needed 4x bigger.
yep. that's a concern. buffered printk must come with a sound number
of users in this case. otherwise people will just see a massive bump
(x2) in memory usage for no particular reason.
> I have an array of 4 buffers, and the following code:
>
> static char *get_trace_buf(void)
> {
> struct trace_buffer_struct *buffer = this_cpu_ptr(trace_percpu_buffer);
>
> if (!buffer || buffer->nesting >= 4)
> return NULL;
>
> return &buffer->buffer[buffer->nesting++][0];
> }
>
> Hmm, I probably need to add a "barrier()" before the return, or use a
> this_cpu_inc() on nesting. As long as the nesting variable is updated
> before the return of the buffer being used, then everything is fine.
> Because we have:
>
> static void put_trace_buf(void)
> {
> this_cpu_dec(trace_percpu_buffer->nesting);
> }
>
> And anything that preempts this call will have returned it back to its
> original state before returning.
there is a tiny-tiny-tiny chance of losing some very specific messages
from the top most context. consider the following
trace_printk("fat fingers %o\n", 100);
from the NMI (nesting 3) context. vscnprintf() must
WARN_ONCE(1, "Unsupported flags modifier: %c\n", fmt[1]);
which will be lost - we are above the nesting limit buffer->nesting >= 4.
// vscnprintf()->... has several more recursion entry points.
-ss
next prev parent reply other threads:[~2017-09-06 2:17 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
2017-09-04 5:41 ` Joe Perches
2017-09-05 14:54 ` Steven Rostedt
2017-09-06 2:14 ` Sergey Senozhatsky [this message]
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=20170906021426.GA6773@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).