From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Steven Rostedt <rostedt@goodmis.org>,
Petr Mladek <pmladek@suse.com>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: Regression in dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") [Was: Regression in fd5f7cde1b85 ("...")]
Date: Wed, 18 Sep 2019 16:52:52 +0900 [thread overview]
Message-ID: <20190918075252.GA30808@jagdpanzerIV> (raw)
In-Reply-To: <20190918071158.rtw45jch2roa2wum@pengutronix.de>
On (09/18/19 09:11), Uwe Kleine-König wrote:
> I rechecked and indeed fd5f7cde1b85's parent has the problem, too, so I
> did a mistake during my bisection :-|
>
> Redoing the bisection (a bit quicker this time) points to
>
> dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes")
>
> Sorry for the confusion.
No worries!
[..]
> > So I'd say that lockdep is correct, but there are several hacks which
> > prevent actual deadlock.
>
> Just to make sure, I got you right: With the way lockdep works it is
> right to assume there is a problem, but in fact there isn't?
I'd probably say so... Unless I'm missing something.
sysrq-over-serial is handled from the serial driver's IRQ handler,
under serial driver's port->lock. sysrq handling calls printk(), which
takes console_sem/owner and re-enters the serial driver via ->write()
callback.
So lockdep sees a reverse locking pattern: port->lock goes before
console_sem/owner, which is not the usual order.
> This is IMHO unfortunate because such false positives reduces the
> usefulness of lockdep considerably. :-|
I agree.
port->sysrq state is global to uart port. IOW, if CPUA sets port->sysrq
then all printk->write() paths (from any other CPU) become lockless.
This makes me wonder is we really need to hold port->lock for
uart_handle_sysrq_char(). I sort of doubt it...
Can you try the following patch? It's against linux-next, I guess
you can backport to your kernel.
The basic idea is to handle sysrq out of port->lock.
I didn't test it all (not even sure if it compiles).
---
drivers/tty/serial/imx.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 87c58f9f6390..f0dd807b52df 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -731,9 +731,9 @@ static irqreturn_t imx_uart_rxint(int irq, void *dev_id)
struct imx_port *sport = dev_id;
unsigned int rx, flg, ignored = 0;
struct tty_port *port = &sport->port.state->port;
+ unsigned long flags;
- spin_lock(&sport->port.lock);
-
+ uart_port_lock_irqsave(&sport->port, flags);
while (imx_uart_readl(sport, USR2) & USR2_RDR) {
u32 usr2;
@@ -749,8 +749,8 @@ static irqreturn_t imx_uart_rxint(int irq, void *dev_id)
continue;
}
- if (uart_handle_sysrq_char(&sport->port, (unsigned char)rx))
- continue;
+ if (uart_prepare_sysrq_char(&sport->port, (unsigned char)rx))
+ break;
if (unlikely(rx & URXD_ERR)) {
if (rx & URXD_BRK)
@@ -792,7 +792,7 @@ static irqreturn_t imx_uart_rxint(int irq, void *dev_id)
}
out:
- spin_unlock(&sport->port.lock);
+ uart_unlock_and_check_sysrq(&sport->port, flags);
tty_flip_buffer_push(port);
return IRQ_HANDLED;
}
next prev parent reply other threads:[~2019-09-18 7:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 14:10 Regression in fd5f7cde1b85 ("printk: Never set console_may_schedule in console_trylock()") Uwe Kleine-König
2019-09-18 1:30 ` Sergey Senozhatsky
2019-09-18 7:11 ` Regression in dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") [Was: Regression in fd5f7cde1b85 ("...")] Uwe Kleine-König
2019-09-18 7:52 ` Sergey Senozhatsky [this message]
2019-09-26 8:58 ` Petr Mladek
2019-09-27 4:26 ` 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=20190918075252.GA30808@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=u.kleine-koenig@pengutronix.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