From: Ingo Molnar <mingo@elte.hu>
To: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Cc: Nick Piggin <npiggin@suse.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Laurent Riffard <laurent.riffard@free.fr>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: [PATCH] sched: improve preempt debugging
Date: Mon, 26 Jan 2009 16:22:13 +0100 [thread overview]
Message-ID: <20090126152213.GI9128@elte.hu> (raw)
In-Reply-To: <20090126151521.8534.46503.stgit@nx>
* Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> From: Alexey Zaytsev <alexey.zaytsev@gmail.com>
> Subject: [PATCH] Set the initial softirq preempt count to SOFTIRQ_OFFSET
>
> Does not changes the preemption semantics, as the
> softirq's obviously can't be preempted, but fixes
> a spurious warning in sub_preempt_count, which
> happens when the preempt count is returned to
> zero, and the interrupted thread is holding the
> BKL.
>
> Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
applied to tip/sched/urgent, thanks Alexey.
I also re-added Nick's original patch on top of that (see it below) - this
way we'll see whether it's all sorted out for good.
Thanks,
Ingo
------------------>
>From ed094285f3495ad5393fc424011c926f1b6138c1 Mon Sep 17 00:00:00 2001
From: Nick Piggin <nickpiggin@yahoo.com.au>
Date: Tue, 30 Sep 2008 20:50:27 +1000
Subject: [PATCH] sched: improve preempt debugging
This patch helped me out with a problem I recently had....
Basically, when the kernel lock is held, then preempt_count underflow does not
get detected until it is released which may be a long time (and arbitrarily,
eg at different points it may be rescheduled). If the bkl is released at
schedule, the resulting output is actually fairly cryptic...
With any other lock that elevates preempt_count, it is illegal to schedule
under it (which would get found pretty quickly). bkl allows scheduling with
preempt_count elevated, which makes underflows hard to debug.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
[ This is a re-try of this commit:
7317d7b: sched: improve preempt debugging
which was reverted in:
01e3eb8: Revert "sched: improve preempt debugging"
because this commit:
d04d99d: x86: set the initial softirq preempt count to SOFTIRQ_OFFSET
Fixes the real cause of the spurious warning. ]
---
kernel/sched.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 52bbf1c..8c2be1e 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4440,7 +4440,7 @@ void __kprobes sub_preempt_count(int val)
/*
* Underflow?
*/
- if (DEBUG_LOCKS_WARN_ON(val > preempt_count()))
+ if (DEBUG_LOCKS_WARN_ON(val > preempt_count() - (!!kernel_locked())))
return;
/*
* Is the spinlock portion underflowing?
prev parent reply other threads:[~2009-01-26 15:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0090126150909.GG9128@elte.hu>
2009-01-26 15:17 ` next-20090107: WARNING: at kernel/sched.c:4435 Alexey Zaytsev
2009-01-26 15:22 ` Ingo Molnar [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=20090126152213.GI9128@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=alexey.zaytsev@gmail.com \
--cc=laurent.riffard@free.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.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