All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: bugzilla-daemon@bugzilla.kernel.org
Cc: sergey.senozhatsky@gmail.com,
	Steven Rostedt <rostedt@goodmis.org>,
	Petr Mladek <pmladek@suse.com>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Bug 199003] console stalled, cause Hard LOCKUP.
Date: Wed, 21 Mar 2018 16:28:51 +0900	[thread overview]
Message-ID: <20180321072851.GB468@jagdpanzerIV> (raw)
In-Reply-To: <bug-199003-14532-4aWzZJgGHz@https.bugzilla.kernel.org/>

On (03/20/18 09:34), bugzilla-daemon@bugzilla.kernel.org wrote:
[..]
> Thanks very much.
> commit e480af09c49736848f749a43dff2c902104f6691 avoided the NMI watchdog
> trigger.

Hm, okay... But "touch_nmi_watchdog() everywhere printk/console-related"
is not exactly where I wanted us to be.

By the way e480af09c49736848f749a43dff2c902104f6691 is from 2006.
Are you sure you meant exactly that commit? What kernel do you use?


Are you saying that none of Steven's patches helped on your setups?


> And this patch may  avdoid long time blocking:
> https://lkml.org/lkml/2018/3/8/584
> 
> We've test it several days.

Hm, printk_deferred is a bit dangerous; it moves console_unlock() to
IRQ. So you still can have the problem of stuck CPUs, it's just now
you shut up the watchdog. Did you test Steven's patches?


A tricky part about printk_deferred() is that it does not use hand off
mechanism. And even more...  What we have with "printk vs printk"
sceanrio

	CPU0			CPU1		...		CPUN

	printk			printk
	 console_unlock 	 hand off			printk
	 			  console_unlock		 hand off
								  console_unlock

turns into a good old "one CPU prints it all" when we have "printk vs
printk_deferred" case. Because printk_deferred just log_store messages
and then _may be_ it grabs the console_sem from IRQ and invokes
console_unlock().

So it's something like this

	CPU0			CPU1		...		CPUN

	printk			printk_deffered
	 console_unlock						printk_deferred
	 console_unlock
	 console_unlock
	...			...				...
				printk_deffered			printk_deferred
	 console_unlock
	 console_unlock


// offtopic  "I can has printk_kthread?"



You now touch_nmi_watchdog() from the console driver [well... at least this
is what e480af09c4973 is doing, but I'm not sure I see how come you didn't
have it applied], so that's why you don't see hard lockups on that CPU0. But
your printing CPU still can stuck, which will defer RCUs on that CPU, etc.
etc. etc. So I'd say that those two approaches

		printk_deferred + touch_nmi_watchdog

combined can do quite some harm. One thing for sure - they don't really fix
any problems.

	-ss

  parent reply	other threads:[~2018-03-21  7:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-199003-14532@https.bugzilla.kernel.org/>
     [not found] ` <bug-199003-14532-lzL5ySZS5x@https.bugzilla.kernel.org/>
2018-03-05  9:27   ` [Bug 199003] console stalled, cause Hard LOCKUP Sergey Senozhatsky
     [not found] ` <bug-199003-14532-4aWzZJgGHz@https.bugzilla.kernel.org/>
2018-03-21  7:28   ` Sergey Senozhatsky [this message]
     [not found] ` <bug-199003-14532-DgJdGAHEOE@https.bugzilla.kernel.org/>
2018-03-26  5:18   ` Sergey Senozhatsky
     [not found] ` <bug-199003-14532-IBTfRpvy7t@https.bugzilla.kernel.org/>
2018-03-27 10:37   ` Sergey Senozhatsky
     [not found] <bug-199003-8243@https.bugzilla.kernel.org/>
     [not found] ` <bug-199003-8243-Txkdkdv5Cm@https.bugzilla.kernel.org/>
2018-03-21 13:44   ` Steven Rostedt
2018-03-22  2:14     ` Sergey Senozhatsky
2018-03-22  2:34       ` Sergey Senozhatsky
2018-03-22 22:25       ` Steven Rostedt
2018-03-23 12:06         ` Sergey Senozhatsky
2018-03-23 13:16           ` Petr Mladek
2018-03-26  5:12             ` Sergey Senozhatsky
2018-03-26  9:26               ` Petr Mladek

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=20180321072851.GB468@jagdpanzerIV \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.