From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: "Sergey Senozhatsky" <sergey.senozhatsky.work@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Paul Mackerras" <paulus@samba.org>,
"Tiezhu Yang" <yangtiezhu@loongson.cn>,
"Rafael Aquini" <aquini@redhat.com>,
"Alexey Kardashevskiy" <aik@ozlabs.ru>,
"Yue Hu" <huyue2@yulong.com>,
"Jordan Niethe" <jniethe5@gmail.com>,
"Kees Cook" <keescook@chromium.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Alistair Popple" <alistair@popple.id.au>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
"Eric Biederman" <ebiederm@xmission.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org, "Cédric Le Goater" <clg@kaod.org>
Subject: Re: [PATCH next v1 2/3] printk: remove safe buffers
Date: Tue, 23 Mar 2021 11:47:06 +0100 [thread overview]
Message-ID: <YFnHKlCvIA2nI41c@alley> (raw)
In-Reply-To: <20210316233326.10778-3-john.ogness@linutronix.de>
On Wed 2021-03-17 00:33:25, John Ogness wrote:
> With @logbuf_lock removed, the high level printk functions for
> storing messages are lockless. Messages can be stored from any
> context, so there is no need for the NMI and safe buffers anymore.
> Remove the NMI and safe buffers.
>
> Although the safe buffers are removed, the NMI and safe context
> tracking is still in place. In these contexts, store the message
> immediately but still use irq_work to defer the console printing.
>
> Since printk recursion tracking is in place, safe context tracking
> for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console lock is left in place. This is
> because the console lock is needed for the actual printing.
I have two more questions after actually checking the entire patch.
See below.
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1084,7 +1069,6 @@ void __init setup_log_buf(int early)
> struct printk_record r;
> size_t new_descs_size;
> size_t new_infos_size;
> - unsigned long flags;
> char *new_log_buf;
> unsigned int free;
> u64 seq;
> @@ -1142,8 +1126,6 @@ void __init setup_log_buf(int early)
> new_descs, ilog2(new_descs_count),
> new_infos);
>
> - printk_safe_enter_irqsave(flags);
> -
> log_buf_len = new_log_buf_len;
> log_buf = new_log_buf;
> new_log_buf_len = 0;
> @@ -1159,8 +1141,6 @@ void __init setup_log_buf(int early)
> */
> prb = &printk_rb_dynamic;
>
> - printk_safe_exit_irqrestore(flags);
This will allow to add new messages from the IRQ context when we
are copying them to the new buffer. They might get lost in
the small race window.
Also the messages from NMI might get lost because they are not
longer stored in the per-CPU buffer.
A possible solution might be to do something like this:
prb_for_each_record(0, &printk_rb_static, seq, &r)
free -= add_to_rb(&printk_rb_dynamic, &r);
prb = &printk_rb_dynamic;
/*
* Copy the remaining messages that might have appeared
* from IRQ or NMI context after we ended copying and
* before we switched the buffers. They must be finalized
* because only one CPU is up at this stage.
*/
prb_for_each_record(seq, &printk_rb_static, seq, &r)
free -= add_to_rb(&printk_rb_dynamic, &r);
> -
> if (seq != prb_next_seq(&printk_rb_static)) {
> pr_err("dropped %llu messages\n",
> prb_next_seq(&printk_rb_static) - seq);
> @@ -2666,7 +2631,6 @@ void console_unlock(void)
> size_t ext_len = 0;
> size_t len;
>
> - printk_safe_enter_irqsave(flags);
> skip:
> if (!prb_read_valid(prb, console_seq, &r))
> break;
> @@ -2711,6 +2675,8 @@ void console_unlock(void)
> printk_time);
> console_seq++;
>
> + printk_safe_enter_irqsave(flags);
What is the purpose of the printk_safe context here, please?
I guess that you wanted to prevent calling console drivers
recursively. But it is already serialized by console_lock().
IMHO, the only risk is when manipulating console_sem->lock
or console_owner_lock. But they are already guarded by
printk_safe context, for example, in console_lock() or
console_lock_spinning_enable().
Do I miss something, please?
> +
> /*
> * While actively printing out messages, if another printk()
> * were to occur on another CPU, it may wait for this one to
> @@ -2745,8 +2711,6 @@ void console_unlock(void)
> * flush, no worries.
> */
> retry = prb_read_valid(prb, console_seq, NULL);
> - printk_safe_exit_irqrestore(flags);
> -
> if (retry && console_trylock())
> goto again;
> }
Heh, all these patches feels like stripping printk of an armour. I hope
that we trained it enough to be flexible and avoid any damage.
Best Regards,
Petr
next prev parent reply other threads:[~2021-03-23 10:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 23:33 [PATCH next v1 0/3] printk: remove safe buffers John Ogness
2021-03-16 23:33 ` [PATCH next v1 2/3] " John Ogness
2021-03-21 5:26 ` Sergey Senozhatsky
2021-03-22 11:16 ` John Ogness
2021-03-22 18:02 ` Petr Mladek
2021-03-22 21:58 ` John Ogness
2021-03-23 9:46 ` Petr Mladek
2021-03-23 10:47 ` Petr Mladek [this message]
2021-03-26 11:12 ` John Ogness
2021-03-29 10:04 ` Petr Mladek
2021-03-29 15:10 ` John Ogness
2021-03-29 15:13 ` John Ogness
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=YFnHKlCvIA2nI41c@alley \
--to=pmladek@suse.com \
--cc=aik@ozlabs.ru \
--cc=akpm@linux-foundation.org \
--cc=alistair@popple.id.au \
--cc=aquini@redhat.com \
--cc=clg@kaod.org \
--cc=ebiederm@xmission.com \
--cc=gpiccoli@canonical.com \
--cc=huyue2@yulong.com \
--cc=jniethe5@gmail.com \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=yangtiezhu@loongson.cn \
/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).