On Thu, 2010-06-17 at 10:46 +0200, John Kacur wrote: > Also as I pointed out, in Sven's case it sounds like they may > have had a build where they even wanted to decrease it. > I hacked the patch below for SLERT 10 a few years ago, and that's shipping still. As you can see from the comment in the patch header, I was aware that this wasn't a closed case, but rather a stop-gap. I think if I had spent any more time on it, or run into the issue repeatedly, my first instinct would have been to do what John did, i.e. make it configurable. However, I think that fundamentally, if nesting goes that deep, simply increasing this define would lead to masking real problems. So while I hacked this up for a shipping product, with intention to debug this later, I'd probably favor a proper fix of the offending call chain upstream. I do not recall ever trying to decrease it, other than to reproduce the issue a few times. I never did have time to dig into it further, and we closed the bug as won't fix for this particular product. Regards, Sven Subject: Increase lockdep's MAX_STACK_TRACE_ENTRIES From: Sven-Thorsten Dietrich <sdietrich@xxxxxxx> For large SMP systems, MAX_STACK_TRACE_ENTRIES was too low, and lockdep would complain. This change addresses the issue on systems we have tested. It remains to be determined whether other bugs (e.g. scheduler balancing issues led to unreasonably deep call chains) Signed-off-by: Sven-Thorsten Dietrich <sdietrich@xxxxxxx> Index: linux-2.6.22/kernel/lockdep_internals.h =================================================================== --- linux-2.6.22.orig/kernel/lockdep_internals.h +++ linux-2.6.22/kernel/lockdep_internals.h @@ -27,7 +27,7 @@ * Stack-trace: tightly packed array of stack backtrace * addresses. Protected by the hash_lock. */ -#define MAX_STACK_TRACE_ENTRIES 262144UL +#define MAX_STACK_TRACE_ENTRIES 524288UL extern struct list_head all_lock_classes; -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
