[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yfyl2TSdFmn7HqmV@google.com>
Date: Fri, 4 Feb 2022 13:04:41 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Stephen Brennan <stephen.s.brennan@...cle.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Petr Mladek <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org,
John Ogness <john.ogness@...utronix.de>
Subject: Re: [PATCH v3 4/4] printk: Drop console_sem during panic
On (22/02/01 10:58), Stephen Brennan wrote:
> +/*
> + * Return true when this CPU should unlock console_sem without pushing all
> + * messages to the console. This reduces the chance that the console is
> + * locked when the panic CPU tries to use it.
> + */
> +static bool abandon_console_lock_in_panic(void)
> +{
> + if (!panic_in_progress())
> + return false;
> +
> + /*
> + * We can use raw_smp_processor_id() here because it is impossible for
> + * the task to be migrated to the panic_cpu, or away from it. If
> + * panic_cpu has already been set, and we're not currently executing on
> + * that CPU, then we never will be.
> + */
> + return atomic_read(&panic_cpu) != raw_smp_processor_id();
> +}
> +
> /*
> * Can we actually use the console at this time on this cpu?
> *
> @@ -2746,6 +2765,10 @@ void console_unlock(void)
> if (handover)
> return;
>
> + /* Allow panic_cpu to take over the consoles safely */
> + if (abandon_console_lock_in_panic())
> + break;
Sorry, why not just `return` like in handover case?
> +
> if (do_cond_resched)
> cond_resched();
> }
> @@ -2763,7 +2786,7 @@ void console_unlock(void)
> * flush, no worries.
> */
> retry = prb_read_valid(prb, next_seq, NULL);
> - if (retry && console_trylock())
> + if (retry && !abandon_console_lock_in_panic() && console_trylock())
> goto again;
> }
> EXPORT_SYMBOL(console_unlock);
Powered by blists - more mailing lists