[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YfK2ekZdiM/lJOEW@alley>
Date: Thu, 27 Jan 2022 16:12:58 +0100
From: Petr Mladek <pmladek@...e.com>
To: Stephen Brennan <stephen.s.brennan@...cle.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Arnd Bergmann <arnd@...db.de>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sebastian Reichel <sre@...nel.org>,
John Ogness <john.ogness@...utronix.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Luis Chamberlain <mcgrof@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/4] printk: Drop console_sem during panic
On Wed 2022-01-26 15:02:36, Stephen Brennan wrote:
> If another CPU is in panic, we are about to be halted. Try to gracefully
> abandon the console_sem, leaving it free for the panic CPU to grab.
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 18107db118d4..572363ff716f 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2742,6 +2761,10 @@ void console_unlock(void)
> if (handover)
> return;
>
> + /* Allow panic_cpu to take over the consoles safely */
> + if (abandon_console_lock_in_panic())
> + break;
Hmm, it makes some sense to have it before cond_resched(). But I would
like to have it at the beginning of the cycle so that console_unlock()
might leave quickly without processing any single message.
We could have it in both (three) locations. But it might be over
cautious.
Anyway, the beginning is more important. Sleeping with console_sem is
less risky from the panic and races point of view.
Best Regards,
Petr
Powered by blists - more mailing lists