[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YFnYiQX99oVv3JpU@alley>
Date: Tue, 23 Mar 2021 13:01:13 +0100
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH next v1 3/3] printk: convert @syslog_lock to spin_lock
On Wed 2021-03-17 00:33:26, John Ogness wrote:
> @syslog_log was a raw_spin_lock to simplify the transition of
s/syslog_log/syslog_lock/
Same problem is also below.
> removing @logbuf_lock and the safe buffers. With that transition
> complete, @syslog_log can become a spin_lock.
I know that we already talked about this. But I want to be sure
that this patch makes sense.
It will actually not change the behavior because we always
take the lock with interrupts disabled.
We disable the interrupts because register_console() is called
in IRQ context on parisc in handle_interruption() when it is
going to panic (code == 1 => will call parisc_terminate()).
Disabling IRQ will not help in parisc_terminate(). This code
path is non-maskable and never returns. The deadlock might be
prevented only by trylock.
trylock on syslog_lock is only small problem. Much bigger is
is a deadlock on console_lock. Fixing this is beyond this
patchset.
Summary:
+ disabling IRQ does not help for parisc
+ register_console() is not irq safe in general because
of the sleeping console_lock.
I would personally prefer to remove both "raw" and "irq"
in this patch and just document the problem with parisc
in the commit message.
IMHO, it does not make sense to keep _irq when it neither
helps nor makes sense.
Best Regards,
Petr
Powered by blists - more mailing lists