From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH next v1 3/3] printk: convert @syslog_lock to spin_lock
Date: Tue, 23 Mar 2021 13:01:13 +0100 [thread overview]
Message-ID: <YFnYiQX99oVv3JpU@alley> (raw)
In-Reply-To: <20210316233326.10778-4-john.ogness@linutronix.de>
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
next prev parent reply other threads:[~2021-03-23 12:02 UTC|newest]
Thread overview: 23+ 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 1/3] printk: track/limit recursion John Ogness
2021-03-21 5:34 ` Sergey Senozhatsky
2021-03-22 10:53 ` John Ogness
2021-03-22 11:13 ` Sergey Senozhatsky
2021-03-22 15:07 ` Petr Mladek
2021-03-22 14:49 ` Petr Mladek
2021-03-23 21:32 ` John Ogness
2021-03-24 8:41 ` Petr Mladek
2021-03-16 23:33 ` [PATCH next v1 2/3] printk: remove safe buffers 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
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
2021-03-16 23:33 ` [PATCH next v1 3/3] printk: convert @syslog_lock to spin_lock John Ogness
2021-03-23 12:01 ` Petr Mladek [this message]
2021-03-26 11:23 ` 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=YFnYiQX99oVv3JpU@alley \
--to=pmladek@suse.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®