From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Daniel Wang <wonderfly@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Jiri Slaby <jslaby@suse.com>, Peter Feiner <pfeiner@google.com>,
linux-serial@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC PATCH v1 15/25] printk: print history for new consoles
Date: Tue, 26 Feb 2019 16:22:01 +0100 [thread overview]
Message-ID: <87o96yziau.fsf@linutronix.de> (raw)
In-Reply-To: <20190226145837.wl54fr7rn2ii5oxc@pathway.suse.cz> (Petr Mladek's message of "Tue, 26 Feb 2019 15:58:37 +0100")
On 2019-02-26, Petr Mladek <pmladek@suse.com> wrote:
>> When new consoles register, they currently print how many messages
>> they have missed. However, many (or all) of those messages may still
>> be in the ring buffer. Add functionality to print as much of the
>> history as available. This is a clean replacement of the old
>> exclusive console hack.
>>
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index 897219f34cab..6c875abd7b17 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -1506,6 +1506,77 @@ static void format_text(struct printk_log *msg, u64 seq,
>> }
>> }
>>
>> +static void printk_write_history(struct console *con, u64 master_seq)
>> +{
>> + struct prb_iterator iter;
>> + bool time = printk_time;
>> + static char *ext_text;
>> + static char *text;
>> + static char *buf;
>> + u64 seq;
>> +
>> + ext_text = kmalloc(CONSOLE_EXT_LOG_MAX, GFP_KERNEL);
>> + text = kmalloc(PRINTK_SPRINT_MAX, GFP_KERNEL);
>> + buf = kmalloc(PRINTK_RECORD_MAX, GFP_KERNEL);
>> + if (!ext_text || !text || !buf)
>> + return;
>
> We need to free buffers that were successfully allocated.
Ouch. You just found some crazy garbage. The char-pointers are
static. The bug is that it allocates each time a console is
registered. It was supposed to be lazy allocation:
if (!ext_text)
ext_text = kmalloc(CONSOLE_EXT_LOG_MAX, GFP_KERNEL);
>> + if (!(con->flags & CON_ENABLED))
>> + goto out;
>> +
>> + if (!con->write)
>> + goto out;
>> +
>> + if (!cpu_online(raw_smp_processor_id()) &&
>> + !(con->flags & CON_ANYTIME))
>> + goto out;
>> +
>> + prb_iter_init(&iter, &printk_rb, NULL);
>> +
>> + for (;;) {
>> + struct printk_log *msg;
>> + size_t ext_len;
>> + size_t len;
>> + int ret;
>> +
>> + ret = prb_iter_next(&iter, buf, PRINTK_RECORD_MAX, &seq);
>> + if (ret == 0) {
>> + break;
>> + } else if (ret < 0) {
>> + prb_iter_init(&iter, &printk_rb, NULL);
>> + continue;
>> + }
>> +
>> + if (seq > master_seq)
>> + break;
>> +
>> + con->printk_seq++;
>> + if (con->printk_seq < seq) {
>> + print_console_dropped(con, seq - con->printk_seq);
>> + con->printk_seq = seq;
>> + }
>> +
>> + msg = (struct printk_log *)buf;
>> + format_text(msg, master_seq, ext_text, &ext_len, text,
>> + &len, time);
>> +
>> + if (len == 0 && ext_len == 0)
>> + continue;
>> +
>> + if (con->flags & CON_EXTENDED)
>> + con->write(con, ext_text, ext_len);
>> + else
>> + con->write(con, text, len);
>> +
>> + printk_delay(msg->level);
>
> Hmm, this duplicates a lot of code from call_console_drivers() and
> maybe also from printk_kthread_func(). It is error prone. People
> will forget to update this function when working on the main one.
>
> We need to put the shared parts into separate functions.
Agreed.
>> + }
>> +out:
>> + con->wrote_history = 1;
>> + kfree(ext_text);
>> + kfree(text);
>> + kfree(buf);
>> +}
>> +
>> /*
>> * Call the console drivers, asking them to write out
>> * log_buf[start] to log_buf[end - 1].
>> @@ -1524,6 +1595,10 @@ static void call_console_drivers(u64 seq, const char *ext_text, size_t ext_len,
>> for_each_console(con) {
>> if (!(con->flags & CON_ENABLED))
>> continue;
>> + if (!con->wrote_history) {
>> + printk_write_history(con, seq);
>
> This looks like an alien. The code is supposed to write one message
> from the given buffer. And some huge job is well hidden there.
This is a very simple implementation of a printk kthread. It probably
makes more sense to have a printk kthread per console. That would allow
fast consoles to not be penalized by slow consoles. Due to the
per-console seq tracking, the code would already support it.
> In addition, the code is actually recursive. It will become
> clear when it is deduplicated as suggested above. We should
> avoid it when it is not necessary. Note that recursive code
> is always more prone to mistakes and it is harder to think of.
Agreed.
> I guess that the motivation is to do everything from the printk
> kthread. Is it really necessary? register_console() takes
> console_lock(). It has to be sleepable context by definition.
It is not necessary. It is desired. Why should _any_ task be punished
with console writing? That is what the printk kthread is for.
John Ogness
next prev parent reply other threads:[~2019-02-26 15:22 UTC|newest]
Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 14:29 [RFC PATCH v1 00/25] printk: new implementation John Ogness
2019-02-12 14:29 ` [RFC PATCH v1 01/25] printk-rb: add printk ring buffer documentation John Ogness
2019-02-12 14:45 ` Greg Kroah-Hartman
2019-02-12 14:29 ` [RFC PATCH v1 02/25] printk-rb: add prb locking functions John Ogness
2019-02-13 15:45 ` Petr Mladek
2019-02-13 21:39 ` John Ogness
2019-02-14 10:33 ` Petr Mladek
2019-02-14 12:10 ` John Ogness
2019-02-15 10:26 ` Petr Mladek
2019-02-15 10:56 ` John Ogness
2019-03-07 2:12 ` Sergey Senozhatsky
2019-02-12 14:29 ` [RFC PATCH v1 03/25] printk-rb: define ring buffer struct and initializer John Ogness
2019-02-12 14:46 ` Greg Kroah-Hartman
2019-02-14 12:46 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 04/25] printk-rb: add writer interface John Ogness
2019-02-14 15:16 ` Petr Mladek
2019-02-14 23:36 ` John Ogness
2019-02-15 1:19 ` John Ogness
2019-02-15 13:47 ` Petr Mladek
2019-02-17 1:32 ` John Ogness
2019-02-21 13:51 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 05/25] printk-rb: add basic non-blocking reading interface John Ogness
2019-02-18 12:54 ` Petr Mladek
2019-02-19 21:44 ` John Ogness
2019-02-21 16:22 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 06/25] printk-rb: add blocking reader support John Ogness
2019-02-18 14:05 ` Petr Mladek
2019-02-19 21:47 ` John Ogness
2019-02-12 14:29 ` [RFC PATCH v1 07/25] printk-rb: add functionality required by printk John Ogness
2019-02-12 17:15 ` Linus Torvalds
2019-02-13 9:20 ` John Ogness
2019-02-18 15:59 ` Petr Mladek
2019-02-19 22:08 ` John Ogness
2019-02-22 9:58 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 08/25] printk: add ring buffer and kthread John Ogness
2019-02-12 15:47 ` Sergey Senozhatsky
2019-02-19 13:54 ` Petr Mladek
2019-03-04 7:38 ` Sergey Senozhatsky
2019-03-04 10:00 ` Sergey Senozhatsky
2019-03-04 11:07 ` Sergey Senozhatsky
2019-03-05 21:00 ` John Ogness
2019-03-06 15:57 ` Petr Mladek
2019-03-06 21:17 ` John Ogness
2019-03-06 22:22 ` John Ogness
2019-03-07 6:41 ` Sergey Senozhatsky
2019-03-07 6:51 ` Sergey Senozhatsky
2019-03-07 12:50 ` Petr Mladek
2019-03-07 5:15 ` Sergey Senozhatsky
2019-03-11 10:51 ` John Ogness
2019-03-12 9:58 ` Sergey Senozhatsky
2019-03-12 10:30 ` Petr Mladek
2019-03-07 12:06 ` John Ogness
2019-03-08 1:31 ` Sergey Senozhatsky
2019-03-08 10:04 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 09/25] printk: remove exclusive console hack John Ogness
2019-02-19 14:03 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 10/25] printk: redirect emit/store to new ringbuffer John Ogness
2019-02-20 9:01 ` Petr Mladek
2019-02-20 21:25 ` John Ogness
2019-02-22 14:43 ` Petr Mladek
2019-02-22 15:06 ` John Ogness
2019-02-22 15:25 ` Petr Mladek
2019-02-25 12:11 ` Petr Mladek
2019-02-25 16:41 ` John Ogness
2019-02-26 9:45 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 11/25] printk_safe: remove printk safe code John Ogness
2019-02-22 10:37 ` Petr Mladek
2019-02-22 10:37 ` Petr Mladek
2019-02-22 13:38 ` John Ogness
2019-02-22 15:15 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 12/25] printk: minimize console locking implementation John Ogness
2019-02-25 13:44 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 13/25] printk: track seq per console John Ogness
2019-02-25 14:59 ` Petr Mladek
2019-02-26 8:45 ` John Ogness
2019-02-26 13:11 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 14/25] printk: do boot_delay_msec inside printk_delay John Ogness
2019-02-12 14:29 ` [RFC PATCH v1 15/25] printk: print history for new consoles John Ogness
2019-02-26 14:58 ` Petr Mladek
2019-02-26 15:22 ` John Ogness [this message]
2019-02-27 9:02 ` Petr Mladek
2019-02-27 10:02 ` John Ogness
2019-02-27 13:12 ` Petr Mladek
2019-03-04 9:24 ` Sergey Senozhatsky
2019-02-12 14:29 ` [RFC PATCH v1 16/25] printk: implement CON_PRINTBUFFER John Ogness
2019-02-26 15:38 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 17/25] printk: add processor number to output John Ogness
2019-02-13 22:29 ` John Ogness
2019-02-12 14:29 ` [RFC PATCH v1 18/25] console: add write_atomic interface John Ogness
2019-02-12 14:29 ` [RFC PATCH v1 19/25] printk: introduce emergency messages John Ogness
2019-03-07 7:30 ` Sergey Senozhatsky
2019-03-08 10:31 ` Petr Mladek
2019-03-11 12:04 ` John Ogness
2019-03-12 2:51 ` Sergey Senozhatsky
2019-03-12 2:58 ` Sergey Senozhatsky
2019-02-12 14:29 ` [RFC PATCH v1 20/25] serial: 8250: implement write_atomic John Ogness
2019-02-27 9:46 ` Petr Mladek
2019-02-27 10:32 ` John Ogness
2019-02-27 13:55 ` Petr Mladek
2019-03-08 4:05 ` John Ogness
2019-03-08 4:17 ` John Ogness
2019-03-08 10:28 ` Petr Mladek
2019-02-12 14:29 ` [RFC PATCH v1 21/25] printk: implement KERN_CONT John Ogness
2019-02-12 14:30 ` [RFC PATCH v1 22/25] printk: implement /dev/kmsg John Ogness
2019-02-12 14:30 ` [RFC PATCH v1 23/25] printk: implement syslog John Ogness
2019-02-12 14:30 ` [RFC PATCH v1 24/25] printk: implement kmsg_dump John Ogness
2019-02-12 14:30 ` [RFC PATCH v1 25/25] printk: remove unused code John Ogness
2019-03-08 14:02 ` Sebastian Andrzej Siewior
2019-03-11 2:46 ` Sergey Senozhatsky
2019-03-11 8:18 ` Sebastian Andrzej Siewior
2019-03-12 9:38 ` Petr Mladek
2019-02-13 1:31 ` [RFC PATCH v1 00/25] printk: new implementation Sergey Senozhatsky
2019-02-13 13:43 ` John Ogness
2019-03-04 6:39 ` Sergey Senozhatsky
2019-02-13 1:41 ` Sergey Senozhatsky
2019-02-13 14:15 ` John Ogness
2019-03-04 5:31 ` Sergey Senozhatsky
2019-02-13 2:55 ` Sergey Senozhatsky
2019-02-13 14:43 ` John Ogness
2019-03-04 5:23 ` Sergey Senozhatsky
2019-03-07 9:53 ` John Ogness
2019-03-08 10:00 ` Petr Mladek
2019-03-11 10:54 ` Sergey Senozhatsky
2019-03-12 12:38 ` Petr Mladek
2019-03-12 15:15 ` John Ogness
2019-03-13 2:15 ` Sergey Senozhatsky
2019-03-13 8:19 ` John Ogness
2019-03-13 8:40 ` Sebastian Siewior
2019-03-13 9:27 ` Sergey Senozhatsky
2019-03-13 10:06 ` Sergey Senozhatsky
2019-03-14 9:27 ` Petr Mladek
2019-03-13 8:46 ` Sergey Senozhatsky
2019-03-14 9:14 ` Petr Mladek
2019-03-14 9:35 ` John Ogness
2019-03-13 2:00 ` Sergey Senozhatsky
2019-02-13 16:54 ` David Laight
2019-02-13 22:20 ` John Ogness
2019-02-13 22:20 ` John Ogness
2020-01-20 23:05 ` Eugeniu Rosca
2020-01-21 23:56 ` John Ogness
2020-01-22 2:34 ` Eugeniu Rosca
2020-01-22 7:31 ` Geert Uytterhoeven
2020-01-22 16:58 ` Eugeniu Rosca
2020-01-22 19:48 ` Geert Uytterhoeven
2020-01-24 16:09 ` Eugeniu Rosca
2020-01-27 12:32 ` Petr Mladek
2020-01-27 13:45 ` Eugeniu Rosca
2020-01-22 10:33 ` John Ogness
2020-01-24 12:13 ` Eugeniu Rosca
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=87o96yziau.fsf@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pfeiner@google.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=wonderfly@google.com \
/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.