public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
 }

  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