From: John Ogness <john.ogness@linutronix.de>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Thomas Gleixner <tglx@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
Date: Tue, 25 Jun 2019 14:03:39 +0200 [thread overview]
Message-ID: <87woh9hnxg.fsf@linutronix.de> (raw)
In-Reply-To: <20190625100322.GD532@jagdpanzerIV> (Sergey Senozhatsky's message of "Tue, 25 Jun 2019 19:03:22 +0900")
On 2019-06-25, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
>>>> In vprintk_emit(), are we going to always reserve 1024-byte
>>>> records, since we don't know the size in advance, e.g.
>>>>
>>>> printk("%pS %s\n", regs->ip, current->name)
>>>> prb_reserve(&e, &rb, ????);
>>>>
>>>> or are we going to run vscnprintf() on a NULL buffer first,
>>>> then reserve the exactly required number of bytes and afterwards
>>>> vscnprintf(s) -> prb_commit(&e)?
>>>
>>> (As suggested by Petr) I want to use vscnprintf() on a NULL
>>> buffer. However, a NULL buffer is not sufficient because things like the
>>> loglevel are sometimes added via %s (for example, in /dev/kmsg). So
>>> rather than a NULL buffer, I would use a small buffer on the stack
>>> (large enough to store loglevel/cont information). This way we can use
>>> vscnprintf() to get the exact size _and_ printk_get_level() will see
>>> enough of the formatted string to parse what it needs.
>>
>> vscnprintf() with NULL pointer is perfectly fine. Only the formatted
>> string has variable size.
>
> Yeah, that should work. Probably. Can't think of any issues, except
> for increased CPU usage. Some sprintf() format specifiers are heavier
> than the rest (pS/pF on ia64/ppc/hppa).
>
> OK, very theoretically.
>
> There is a difference.
>
> Doing "sz = vscprintf(NULL, msg); vscnprintf(buf, sz, msg)" for
> msg_print_text() and msg_print_ext_header() was safe, because the
> data - msg - would not change under us, we would work with logbuf
> records, IOW with data which is owned by printk() and printk only.
>
> But doing
> sz = vcsprintf(NULL, "xxx", random_pointer);
> if ((buf = prb_reserve(... sz))) {
> vscnprintf(buf, sz, "xxx", random_pointer);
> prb_commit(...);
> }
>
> might have different outcome sometimes. We probably (!!!) can have
> some race conditions. The problem is that, unlike msg_print_text()
> and msg_print_ext_header(), printk() works with pointers which it
> does not own nor control. IOW within single printk() we will access
> some random kernel pointers, then do prb stuff, then access those
> same pointers, expecting that none of them will ever change their
> state. A very simple example
>
> printk("Comm %s\n", current->comm)
>
> Suppose printk on CPU0 and ia64_mca_modify_comm on CPU1
>
> CPU0 CPU1
> printk(...)
> sz = vscprintf(NULL, "Comm %s\n", current->comm);
> ia64_mca_modify_comm()
> snprintf(comm, sizeof(comm), "%s %d", current->comm, previous_current->pid);
> memcpy(current->comm, comm, sizeof(current->comm));
> if ((buf = prb_reserve(... sz))) {
> vscnprintf(buf, "Comm %s\n", current->comm);
> ^^^^^^^^^^^^^^ ->comm has changed.
> Nothing critical, we
> should not corrupt
> anything, but we will
> truncate ->comm if its
> new size is larger than
> what it used to be when
> we did vscprintf(NULL).
> prb_commit(...);
> }
>
> Probably there can be other examples.
This is a very good point, and quite important. It is not acceptable if
some crash output is cut off because of this effect.
In my v1 rfc series, I avoided this issue by having a separate dedicated
ringbuffer (rb_sprintf) that was used to allocate a temporary max-size
(2KB) buffer for sprinting to. Then _that_ was used for the real
ringbuffer input (strlen, prb_reserve, memcpy, prb_commit). That would
still be the approach of my choice.
John Ogness
next prev parent reply other threads:[~2019-06-25 12:03 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 16:23 [RFC PATCH v2 0/2] printk: new ringbuffer implementation John Ogness
2019-06-07 16:23 ` [RFC PATCH v2 1/2] printk-rb: add a new printk " John Ogness
2019-06-18 4:51 ` Sergey Senozhatsky
2019-06-18 22:12 ` John Ogness
2019-06-25 6:45 ` Sergey Senozhatsky
2019-06-25 7:15 ` Sergey Senozhatsky
2019-06-25 8:44 ` John Ogness
2019-06-25 9:06 ` Petr Mladek
2019-06-25 10:03 ` Sergey Senozhatsky
2019-06-25 12:03 ` John Ogness [this message]
2019-06-26 2:08 ` Sergey Senozhatsky
2019-06-26 7:16 ` John Ogness
2019-06-26 7:45 ` Sergey Senozhatsky
2019-06-26 7:47 ` Petr Mladek
2019-06-26 7:59 ` Sergey Senozhatsky
2019-06-25 9:09 ` Sergey Senozhatsky
2019-06-18 11:12 ` Peter Zijlstra
2019-06-18 22:18 ` John Ogness
2019-06-18 11:22 ` Peter Zijlstra
2019-06-18 22:30 ` John Ogness
2019-06-19 10:46 ` Andrea Parri
2019-06-20 22:50 ` John Ogness
2019-06-21 12:16 ` Andrea Parri
2019-06-19 11:08 ` Peter Zijlstra
2019-06-18 11:47 ` Peter Zijlstra
2019-06-20 22:23 ` John Ogness
2019-06-26 22:40 ` Peter Zijlstra
2019-06-26 22:53 ` Peter Zijlstra
2019-06-28 9:50 ` John Ogness
2019-06-28 15:44 ` Peter Zijlstra
2019-06-28 16:07 ` Peter Zijlstra
2019-07-01 10:39 ` John Ogness
2019-07-01 14:10 ` Peter Zijlstra
2019-07-01 14:11 ` Peter Zijlstra
2019-06-29 21:05 ` Andrea Parri
2019-06-30 2:03 ` John Ogness
2019-06-30 14:08 ` Andrea Parri
2019-07-02 14:13 ` John Ogness
2019-06-26 22:47 ` Peter Zijlstra
2019-06-21 14:05 ` Petr Mladek
2019-06-24 8:33 ` John Ogness
2019-06-24 14:09 ` Petr Mladek
2019-06-25 13:29 ` John Ogness
2019-06-26 8:29 ` Petr Mladek
2019-06-26 9:09 ` John Ogness
2019-06-26 21:16 ` Peter Zijlstra
2019-06-26 21:43 ` John Ogness
2019-06-27 8:28 ` Petr Mladek
2019-07-04 10:33 ` [PATCH POC] printk_ringbuffer: Alternative implementation of lockless printk ringbuffer Petr Mladek
2019-07-04 14:59 ` John Ogness
2019-07-08 15:23 ` Petr Mladek
2019-07-09 1:34 ` John Ogness
2019-07-09 9:06 ` Petr Mladek
2019-07-09 10:21 ` John Ogness
2019-07-09 11:58 ` Petr Mladek
2019-08-14 3:46 ` John Ogness
2019-06-24 13:55 ` [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation John Ogness
2019-06-25 8:55 ` Sergey Senozhatsky
2019-06-25 9:19 ` John Ogness
2019-06-07 16:23 ` [RFC PATCH v2 2/2] printk-rb: add test module John Ogness
2019-06-17 21:09 ` [RFC PATCH v2 0/2] printk: new ringbuffer implementation Thomas Gleixner
2019-06-18 7:15 ` Petr Mladek
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=87woh9hnxg.fsf@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=andrea.parri@amarulasolutions.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--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).