LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH printk v1 06/10] printk: use seqcount_latch for console_seq
Date: Thu, 05 Aug 2021 17:32:40 +0206	[thread overview]
Message-ID: <87bl6bx68f.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <YQvWuzpAv1Tw/CoQ@alley>

On 2021-08-05, Petr Mladek <pmladek@suse.com> wrote:
> On Tue 2021-08-03 15:18:57, John Ogness wrote:
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index d07d98c1e846..f8f46d9fba9b 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -2912,18 +2920,19 @@ void console_unblank(void)
>>   */
>>  void console_flush_on_panic(enum con_flush_mode mode)
>>  {
>> -	/*
>> -	 * If someone else is holding the console lock, trylock will fail
>> -	 * and may_schedule may be set.  Ignore and proceed to unlock so
>> -	 * that messages are flushed out.  As this can be called from any
>> -	 * context and we don't want to get preempted while flushing,
>> -	 * ensure may_schedule is cleared.
>> -	 */
>> -	console_trylock();
>> -	console_may_schedule = 0;
>> -
>> -	if (mode == CONSOLE_REPLAY_ALL)
>> -		console_seq = prb_first_valid_seq(prb);
>> +	if (console_trylock()) {
>> +		if (mode == CONSOLE_REPLAY_ALL)
>> +			latched_seq_write(&console_seq, prb_first_valid_seq(prb));
>
> I am scratching my head about this. Of course, latched_seq_write() does
> not guarantee the result when the console lock it taken by another process.
> But console_lock(), called below, will call latched_seq_write()
> anyway.
>
> Also CONSOLE_REPLAY_ALL is used by panic_print_sys_info().
> It is called the following way:
>
> void panic(const char *fmt, ...)
> {
> [...]
> 	debug_locks_off();
> 	console_flush_on_panic(CONSOLE_FLUSH_PENDING);
>
> 	panic_print_sys_info();
> [...]
> }
>
> On one hand, console_flush_on_panic(CONSOLE_FLUSH_PENDING) will
> most likely take over the console lock even when it was taken
> by another CPU before. And the 2nd console_flush_on_panic()
> called from panic_print_sys_info() will not even notice.
>
> On the other hand, CONSOLE_REPLAY_ALL would not even try to
> reply the log when the console log was not available.
>
> The risk of broken console_seq is neglible. console_unlock()
> should be safe even with invalid console_seq.
>
> My opinion:
>
> I suggest to keep the original logic and maybe add some comment:
>
> void console_flush_on_panic(enum con_flush_mode mode)
> {
> 	/*
> 	 * If someone else is holding the console lock, trylock will fail
> 	 * and may_schedule may be set.  Ignore and proceed to unlock so
> 	 * that messages are flushed out.  As this can be called from any
> 	 * context and we don't want to get preempted while flushing,
> 	 * ensure may_schedule is cleared.
> 	 */
> 	console_trylock();
> 	console_may_schedule = 0;
>
> 	/*
> 	 * latched_seq_write() does not guarantee consistent values
> 	 * when console_trylock() failed. But this is the best effort.
> 	 * console_unlock() will update anyway console_seq. prb_read_valid()
> 	 * handles even invalid sequence numbers.
> 	 */
> 	if (mode == CONSOLE_REPLAY_ALL)
> 		latched_seq_write(&console_seq, prb_first_valid_seq(prb));
>
> 	console_unlock();
> }

I see now that CONSOLE_REPLAY_ALL is not handled correctly. And in the
follow-up patch "printk: introduce kernel sync mode" the situation gets
worse. I am trying to find ways to handle things without blindly
ignoring locks and hoping for the best.

I need to re-evaluate how to correctly support this feature.

John Ogness

  reply	other threads:[~2021-08-05 15:26 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03 13:12 [PATCH printk v1 00/10] printk: introduce atomic consoles and sync mode John Ogness
2021-08-03 13:12 ` [PATCH printk v1 01/10] printk: relocate printk cpulock functions John Ogness
2021-08-04  9:24   ` Petr Mladek
2021-08-03 13:12 ` [PATCH printk v1 02/10] printk: rename printk cpulock API and always disable interrupts John Ogness
2021-08-04  9:52   ` Petr Mladek
2021-08-03 13:12 ` [PATCH printk v1 03/10] kgdb: delay roundup if holding printk cpulock John Ogness
2021-08-03 14:25   ` Daniel Thompson
2021-08-03 15:30     ` John Ogness
2021-08-04 11:31       ` Daniel Thompson
2021-08-04 12:12         ` Petr Mladek
2021-08-04 15:04           ` Daniel Thompson
2021-08-05  3:46             ` John Ogness
2021-08-06 12:06               ` Daniel Thompson
2021-08-04 12:31       ` Petr Mladek
2021-08-03 13:12 ` [PATCH printk v1 04/10] printk: relocate printk_delay() John Ogness
2021-08-04 13:07   ` Petr Mladek
2021-08-03 13:12 ` [PATCH printk v1 05/10] printk: call boot_delay_msec() in printk_delay() John Ogness
2021-08-04 13:09   ` Petr Mladek
2021-08-31  1:04   ` Sergey Senozhatsky
2021-08-03 13:12 ` [PATCH printk v1 06/10] printk: use seqcount_latch for console_seq John Ogness
2021-08-05 12:16   ` Petr Mladek
2021-08-05 15:26     ` John Ogness [this message]
2021-08-06 15:56       ` Petr Mladek
2021-08-31  3:05         ` Sergey Senozhatsky
2021-08-03 13:12 ` [PATCH printk v1 07/10] console: add write_atomic interface John Ogness
2021-08-03 14:02   ` Andy Shevchenko
2021-08-06 10:56     ` John Ogness
2021-08-06 11:18       ` Andy Shevchenko
2021-08-31  2:55   ` Sergey Senozhatsky
2021-08-03 13:12 ` [PATCH printk v1 08/10] printk: introduce kernel sync mode John Ogness
2021-08-05 17:11   ` Petr Mladek
2021-08-05 21:25     ` John Ogness
2021-08-03 13:13 ` [PATCH printk v1 09/10] kdb: if available, only use atomic consoles for output mirroring John Ogness
2021-08-03 13:13 ` [PATCH printk v1 10/10] serial: 8250: implement write_atomic John Ogness
2021-08-03 14:07   ` Andy Shevchenko
2021-08-05  7:47     ` Jiri Slaby
2021-08-05  8:26       ` John Ogness
2021-08-03 13:52 ` [PATCH printk v1 00/10] printk: introduce atomic consoles and sync mode Andy Shevchenko
2021-08-05 15:47 ` Petr Mladek
2021-08-31  0:33   ` Sergey Senozhatsky

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=87bl6bx68f.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH printk v1 06/10] printk: use seqcount_latch for console_seq' \
    /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

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).