All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf@tilera.com>
To: <mingo@kernel.org>, <hpa@zytor.com>,
	<linux-kernel@vger.kernel.org>, <satyam@infradead.org>,
	<peterz@infradead.org>, <cmetcalf@tilera.com>,
	<tglx@linutronix.de>, <sboyd@codeaurora.org>
Cc: <linux-tip-commits@vger.kernel.org>
Subject: Re: [tip:sched/urgent] sched: Fix __schedule_bug() output when called from an interrupt
Date: Thu, 29 Mar 2012 09:39:54 -0400	[thread overview]
Message-ID: <4F74662A.7040704@tilera.com> (raw)
In-Reply-To: <tip-6135fc1eb4b1c9ae5f535507ed59591bab51e630@git.kernel.org>

On 3/29/2012 3:16 AM, tip-bot for Stephen Boyd wrote:
> Commit-ID:  6135fc1eb4b1c9ae5f535507ed59591bab51e630
> Gitweb:     http://git.kernel.org/tip/6135fc1eb4b1c9ae5f535507ed59591bab51e630
> Author:     Stephen Boyd <sboyd@codeaurora.org>
> AuthorDate: Wed, 28 Mar 2012 17:10:47 -0700
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Thu, 29 Mar 2012 08:34:45 +0200
>
> sched: Fix __schedule_bug() output when called from an interrupt
>
> If schedule is called from an interrupt handler __schedule_bug()
> will call show_regs() with the registers saved during the
> interrupt handling done in do_IRQ(). This means we'll see the
> registers and the backtrace for the process that was interrupted
> and not the full backtrace explaining who called schedule().
>
> This is due to 838225b ("sched: use show_regs() to improve
> __schedule_bug() output", 2007-10-24) which improperly assumed
> that get_irq_regs() would return the registers for the current
> stack because it is being called from within an interrupt
> handler. Simply remove the show_reg() code so that we dump a
> backtrace for the interrupt handler that called schedule().
>
> [ I ran across this when I was presented with a scheduling while
>   atomic log with a stacktrace pointing at spin_unlock_irqrestore().
>   It made no sense and I had to guess what interrupt handler could
>   be called and poke around for someone calling schedule() in an
>   interrupt handler. A simple test of putting an msleep() in
>   an interrupt handler works better with this patch because you
>   can actually see the msleep() call in the backtrace. ]
>
> Also-reported-by: Chris Metcalf <cmetcalf@tilera.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Satyam Sharma <satyam@infradead.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Link: http://lkml.kernel.org/r/1332979847-27102-1-git-send-email-sboyd@codeaurora.org
> Signed-off-by: Ingo Molnar <mingo@kernel.org>

Acked-by: Chris Metcalf <cmetcalf@tilera.com>

We have been using this same exact patch internally for a while now, and by
a curious fluke of timing, I sent email to Ingo and to Satyam Sharma
pointing out that we really should re-look at the original change just
yesterday :-)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


      reply	other threads:[~2012-03-29 13:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29  0:10 [PATCH] sched: Fix __schedule_bug() output when called from an interrupt Stephen Boyd
2012-03-29  7:16 ` [tip:sched/urgent] " tip-bot for Stephen Boyd
2012-03-29 13:39   ` Chris Metcalf [this message]

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=4F74662A.7040704@tilera.com \
    --to=cmetcalf@tilera.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=satyam@infradead.org \
    --cc=sboyd@codeaurora.org \
    --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 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.