public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Eric Rannaud <eric.rannaud@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	nagar@watson.ibm.com
Subject: Re: BUG-lockdep and freeze (was: Arrr! Linux 2.6.18)
Date: Sun, 1 Oct 2006 00:05:05 +0200	[thread overview]
Message-ID: <20060930220505.GA19338@elte.hu> (raw)
In-Reply-To: <5f3c152b0609301500l52a4c6c5o2052b88621dc7ca3@mail.gmail.com>


* Eric Rannaud <eric.rannaud@gmail.com> wrote:

> On 9/30/06, Andrew Morton <akpm@osdl.org> wrote:
> >You could set CONFIG_UNWIND_INFO=n and CONFIG_STACK_UNWIND=n and reenable
> >lockdep.  That will a) tell us if there's some lockdep problem and b) will
> >give us a clearer look at any locking problems which your kernel is
> >detecting.
> 
> 
> All right. Here is the stacktrace I get with config
> CONFIG_UNWIND_INFO=n and CONFIG_STACK_UNWIND=n and v2.6.18 (all the
> rest being equal  http://engm.ath.cx/kernel/config-2.6.18). (and no
> freeze)

hm, does the patch below solve it? In general, lockdep warnings are 
intended to be non-fatal, so i have put in various practical limits on 
internal data structure failure modes. We havent had a /single/ 
lockdep-internal crash ever since lockdep went upstream [the unwinder 
crashes are outside of lockdep], and that's largely due to the good 
internal checks it does.

Recursion within the dependency graph is currently limited to 20, that's 
probably not enough on your box - this patch doubles it to 40. I have 
written the lockdep functions to have as small stackframes as possible, 
so 40 should be OK too. (The practical recursion limit should be 
somewhere between 100 and 200 entries. If we hit that then i'll change 
the algorithm to be iteration-based. Graph walking logic is so easy to 
program via recursion, so i'd like to keep recursion as long as 
possible.)

	Ingo

---------------->
Subject: lockdep: increase max allowed recursion depth
From: Ingo Molnar <mingo@elte.hu>

With lots of CPUs there can be lots of deep dependencies. Will change 
the algorithm to iteration-based if it gets too deep.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/lockdep.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Index: linux/kernel/lockdep.c
===================================================================
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -575,6 +575,8 @@ static noinline int print_circular_bug_t
 	return 0;
 }
 
+#define RECURSION_LIMIT 40
+
 static int noinline print_infinite_recursion_bug(void)
 {
 	__raw_spin_unlock(&hash_lock);
@@ -595,7 +597,7 @@ check_noncircular(struct lock_class *sou
 	debug_atomic_inc(&nr_cyclic_check_recursions);
 	if (depth > max_recursion_depth)
 		max_recursion_depth = depth;
-	if (depth >= 20)
+	if (depth >= RECURSION_LIMIT)
 		return print_infinite_recursion_bug();
 	/*
 	 * Check this lock's dependency list:
@@ -645,7 +647,7 @@ find_usage_forwards(struct lock_class *s
 
 	if (depth > max_recursion_depth)
 		max_recursion_depth = depth;
-	if (depth >= 20)
+	if (depth >= RECURSION_LIMIT)
 		return print_infinite_recursion_bug();
 
 	debug_atomic_inc(&nr_find_usage_forwards_checks);
@@ -684,7 +686,7 @@ find_usage_backwards(struct lock_class *
 
 	if (depth > max_recursion_depth)
 		max_recursion_depth = depth;
-	if (depth >= 20)
+	if (depth >= RECURSION_LIMIT)
 		return print_infinite_recursion_bug();
 
 	debug_atomic_inc(&nr_find_usage_backwards_checks);

  reply	other threads:[~2006-09-30 22:12 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-30 19:20 BUG-lockdep and freeze (was: Arrr! Linux 2.6.18) Eric Rannaud
2006-09-30 19:49 ` Peter Zijlstra
2006-09-30 20:23   ` Linus Torvalds
2006-09-30 20:57   ` Eric Rannaud
2006-09-30 19:54 ` Linus Torvalds
2006-09-30 20:21   ` Al Viro
2006-09-30 20:28     ` Linus Torvalds
2006-09-30 20:30   ` Andi Kleen
2006-09-30 20:47     ` Linus Torvalds
2006-09-30 20:49       ` Ingo Molnar
2006-09-30 21:11         ` Linus Torvalds
2006-09-30 21:25           ` Ingo Molnar
2006-09-30 21:57           ` Andi Kleen
2006-09-30 22:09             ` BUG-lockdep and freeze (was: Arrr! Linux 2.6.18) II Andi Kleen
2006-09-30 22:19               ` Eric Rannaud
2006-09-30 22:24                 ` Andi Kleen
2006-09-30 22:54             ` BUG-lockdep and freeze (was: Arrr! Linux 2.6.18) Linus Torvalds
2006-10-04  9:21           ` Jan Beulich
2006-10-04 15:12             ` Linus Torvalds
2006-09-30 21:43     ` Eric Rannaud
2006-09-30 22:03       ` Andi Kleen
2006-09-30 21:56     ` Linus Torvalds
2006-09-30 22:02       ` Andi Kleen
2006-09-30 22:10         ` Ingo Molnar
2006-09-30 22:23           ` Andi Kleen
2006-09-30 22:55         ` Linus Torvalds
2006-09-30 22:59           ` Linus Torvalds
2006-09-30 23:56           ` Andi Kleen
2006-10-01  0:25             ` Linus Torvalds
2006-10-01  0:51               ` Linus Torvalds
2006-10-01  9:27                 ` Andi Kleen
2006-10-04  9:25     ` Jan Beulich
2006-10-04 10:52       ` Andi Kleen
2006-10-04 11:58         ` Jan Beulich
2006-10-04 12:03           ` Andi Kleen
2006-10-04 12:10             ` Jan Beulich
2006-09-30 20:43   ` Linus Torvalds
2006-10-04  9:15   ` Jan Beulich
2006-09-30 20:13 ` Andrew Morton
2006-09-30 20:52   ` Eric Rannaud
2006-09-30 21:04     ` Andrew Morton
2006-09-30 22:00       ` Eric Rannaud
2006-09-30 22:05         ` Ingo Molnar [this message]
2006-10-01  0:59           ` Eric Rannaud

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=20060930220505.GA19338@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=eric.rannaud@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nagar@watson.ibm.com \
    --cc=torvalds@osdl.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