public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Christoph Hellwig <hch@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	Gregory Haskins <ghaskins@novell.com>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tim Bird <tim.bird@am.sony.com>, Sam Ravnborg <sam@ravnborg.org>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	John Stultz <johnstul@us.ibm.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 01/23 -v6] printk - dont wakeup klogd with interrupts disabled
Date: Sat, 26 Jan 2008 10:10:15 +0100	[thread overview]
Message-ID: <20080126091015.GA1794@elf.ucw.cz> (raw)
In-Reply-To: <20080126042801.280369398@goodmis.org>

On Fri 2008-01-25 23:21:53, Steven Rostedt wrote:
> [ This patch is added to the series since the wakeup timings trace
>   may lockup without it. ]
> 
> I thought that one could place a printk anywhere without worrying.
> But it seems that it is not wise to place a printk where the runqueue
> lock is held.
> 
> I just spent two hours debugging why some of my code was locking up,
> to find that the lockup was caused by some debugging printk's that
> I had in the scheduler.  The printk's were only in rare paths so
> they shouldn't be too much of a problem, but after I hit the printk
> the system locked up.
> 
> Thinking that it was locking up on my code I went looking down the
> wrong path. I finally found (after examining an NMI dump) that
> the lockup happened because printk was trying to wakeup the klogd
> daemon, which caused a deadlock when the try_to_wakeup code tries
> to grab the runqueue lock.
> 
> This patch adds a runqueue_is_locked interface in sched.c for other
> files to see if the current runqueue lock is held. This is used
> in printk to determine whether it is safe or not to wakeup the klogd.
> 
> And with this patch, my code ran fine ;-)
> 
> Signed-off-by: Steven Rostedt <srostedt@redhat.com>
> ---
>  include/linux/sched.h |    2 ++
>  kernel/printk.c       |   14 ++++++++++----
>  kernel/sched.c        |   18 ++++++++++++++++++
>  3 files changed, 30 insertions(+), 4 deletions(-)
> 
> Index: linux-mcount.git/kernel/printk.c
> ===================================================================
> --- linux-mcount.git.orig/kernel/printk.c	2008-01-25 21:46:50.000000000 -0500
> +++ linux-mcount.git/kernel/printk.c	2008-01-25 21:46:55.000000000 -0500
> @@ -590,9 +590,11 @@ static int have_callable_console(void)
>   * @fmt: format string
>   *
>   * This is printk().  It can be called from any context.  We want it to work.
> - * Be aware of the fact that if oops_in_progress is not set, we might try to
> - * wake klogd up which could deadlock on runqueue lock if printk() is called
> - * from scheduler code.
> + *
> + * Note: if printk() is called with the runqueue lock held, it will not wake
> + * up the klogd. This is to avoid a deadlock from calling printk() in schedule
> + * with the runqueue lock held and having the wake_up grab the runqueue lock
> + * as well.
>   *
>   * We try to grab the console_sem.  If we succeed, it's easy - we log the output and
>   * call the console drivers.  If we fail to get the semaphore we place the output
> @@ -1003,7 +1005,11 @@ void release_console_sem(void)
>  	console_locked = 0;
>  	up(&console_sem);
>  	spin_unlock_irqrestore(&logbuf_lock, flags);
> -	if (wake_klogd)
> +	/*
> +	 * If we try to wake up klogd while printing with the runqueue lock
> +	 * held, this will deadlock.
> +	 */
> +	if (wake_klogd && !runqueue_is_locked())
>  		wake_up_klogd();
>  }

I guess you are going to kill me... but 

CPU0					CPU1
if (!runqueue_is_locked()) {
					locks runqueue
	wake_up_klogd

...and we are dead. What is needed here is
"wake_up_klogd_if_you_can()" or something, that does trylock (atomic).

...but even this version is better than status quo, I'd say.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2008-01-26  9:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-26  4:21 [PATCH 00/23 -v6] mcount and latency tracing utility -v6 Steven Rostedt
2008-01-26  4:21 ` [PATCH 01/23 -v6] printk - dont wakeup klogd with interrupts disabled Steven Rostedt
2008-01-26  9:10   ` Pavel Machek [this message]
2008-01-26  9:52     ` Peter Zijlstra
2008-01-26 13:07       ` Steven Rostedt
2008-01-26 13:48         ` Steven Rostedt
2008-01-26  9:50   ` Peter Zijlstra
2008-01-26 13:03     ` Steven Rostedt
2008-01-26  4:21 ` [PATCH 02/23 -v6] Add basic support for gcc profiler instrumentation Steven Rostedt
2008-01-26  4:21 ` [PATCH 03/23 -v6] Annotate core code that should not be traced Steven Rostedt
2008-01-26  4:21 ` [PATCH 04/23 -v6] x86_64: notrace annotations Steven Rostedt
2008-01-26  4:21 ` [PATCH 05/23 -v6] add notrace annotations to vsyscall Steven Rostedt
2008-01-26  4:21 ` [PATCH 06/23 -v6] add notrace annotations for NMI routines Steven Rostedt
2008-01-26  4:21 ` [PATCH 07/23 -v6] handle accurate time keeping over long delays Steven Rostedt
2008-01-26  4:22 ` [PATCH 08/23 -v6] initialize the clock source to jiffies clock Steven Rostedt
2008-01-26  4:22 ` [PATCH 09/23 -v6] add get_monotonic_cycles Steven Rostedt
2008-01-26  4:22 ` [PATCH 10/23 -v6] add notrace annotations to timing events Steven Rostedt
2008-01-26  4:22 ` [PATCH 11/23 -v6] mcount based trace in the form of a header file library Steven Rostedt
2008-01-26  4:22 ` [PATCH 12/23 -v6] Add context switch marker to sched.c Steven Rostedt
2008-01-26  4:22 ` [PATCH 13/23 -v6] Make the task State char-string visible to all Steven Rostedt
2008-01-26  4:22 ` [PATCH 14/23 -v6] Add tracing of context switches Steven Rostedt
2008-01-26  4:22 ` [PATCH 15/23 -v6] Generic command line storage Steven Rostedt
2008-01-26  4:22 ` [PATCH 16/23 -v6] trace generic call to schedule switch Steven Rostedt
2008-01-26  4:22 ` [PATCH 17/23 -v6] Add marker in try_to_wake_up Steven Rostedt
2008-01-26  4:22 ` [PATCH 18/23 -v6] mcount tracer for wakeup latency timings Steven Rostedt
2008-01-26  4:22 ` [PATCH 19/23 -v6] Trace irq disabled critical timings Steven Rostedt
2008-01-26  4:22 ` [PATCH 20/23 -v6] trace preempt off " Steven Rostedt
2008-01-26  4:22 ` [PATCH 21/23 -v6] Add markers to various events Steven Rostedt
2008-01-26  4:22 ` [PATCH 22/23 -v6] Add event tracer Steven Rostedt
2008-01-26  4:22 ` [PATCH 23/23 -v6] Critical latency timings histogram Steven Rostedt
2008-01-26  9:11   ` Pavel Machek
2008-01-26 13:00     ` Steven Rostedt

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=20080126091015.GA1794@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=fche@redhat.com \
    --cc=ghaskins@novell.com \
    --cc=hch@infradead.org \
    --cc=jan.kiszka@siemens.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=sam@ravnborg.org \
    --cc=srostedt@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tim.bird@am.sony.com \
    --cc=torvalds@linux-foundation.org \
    /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