From 88fecaa27f398d95db6c405a1908292c6f0bc3ef Mon Sep 17 00:00:00 2001 From: john stultz Date: Mon, 3 Jul 2006 00:24:04 -0700 Subject: [PATCH] time initialisation fix We're not reay to take a timer interrupt until timekeeping_init() has run. But time_init() will start the time interrupt and if it is called with local interrupts enabled we'll immediately take an interrupt and die. Fix that by running timekeeping_init() prior to time_init(). We don't know _why_ local interrupts got enabled on Jesse Brandeburg's machine. That's a separate as-yet-unsolved problem. THe patch adds a little bit of debugging to detect that. This whole requirement that local interrupts be held off during early boot keeps on biting us. Signed-off-by: John Stultz Cc: Jesse Brandeburg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- init/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'init/main.c') diff --git a/init/main.c b/init/main.c index b2f3b566790e..c8960b9df623 100644 --- a/init/main.c +++ b/init/main.c @@ -496,8 +496,8 @@ asmlinkage void __init start_kernel(void) init_timers(); hrtimers_init(); softirq_init(); - time_init(); timekeeping_init(); + time_init(); /* * HACK ALERT! This is early. We're enabling the console before @@ -508,6 +508,8 @@ asmlinkage void __init start_kernel(void) if (panic_later) panic(panic_later, panic_param); profile_init(); + if (!irqs_disabled()) + printk("start_kernel(): bug: interrupts were enabled early\n"); local_irq_enable(); #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start && !initrd_below_start_ok && -- cgit v1.2.2 From 93e028148fce0be9787de7fb097fa4c8582b78c1 Mon Sep 17 00:00:00 2001 From: Heiko Carstens Date: Mon, 3 Jul 2006 00:24:24 -0700 Subject: [PATCH] lockdep: console_init after local_irq_enable() s390's console_init must enable interrupts, but early_boot_irqs_on() gets called later. To avoid problems move console_init() after local_irq_enable(). Signed-off-by: Heiko Carstens Acked-by: Ingo Molnar Cc: Martin Schwidefsky Cc: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- init/main.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'init/main.c') diff --git a/init/main.c b/init/main.c index c8960b9df623..d604dfef82b8 100644 --- a/init/main.c +++ b/init/main.c @@ -498,6 +498,10 @@ asmlinkage void __init start_kernel(void) softirq_init(); timekeeping_init(); time_init(); + profile_init(); + if (!irqs_disabled()) + printk("start_kernel(): bug: interrupts were enabled early\n"); + local_irq_enable(); /* * HACK ALERT! This is early. We're enabling the console before @@ -507,10 +511,6 @@ asmlinkage void __init start_kernel(void) console_init(); if (panic_later) panic(panic_later, panic_param); - profile_init(); - if (!irqs_disabled()) - printk("start_kernel(): bug: interrupts were enabled early\n"); - local_irq_enable(); #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start && !initrd_below_start_ok && initrd_start < min_low_pfn << PAGE_SHIFT) { -- cgit v1.2.2 From 9a11b49a805665e13a56aa067afaf81d43ec1514 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Mon, 3 Jul 2006 00:24:33 -0700 Subject: [PATCH] lockdep: better lock debugging Generic lock debugging: - generalized lock debugging framework. For example, a bug in one lock subsystem turns off debugging in all lock subsystems. - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from the mutex/rtmutex debugging code: it caused way too much prototype hackery, and lockdep will give the same information anyway. - ability to do silent tests - check lock freeing in vfree too. - more finegrained debugging options, to allow distributions to turn off more expensive debugging features. There's no separate 'held mutexes' list anymore - but there's a 'held locks' stack within lockdep, which unifies deadlock detection across all lock classes. (this is independent of the lockdep validation stuff - lockdep first checks whether we are holding a lock already) Here are the current debugging options: CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y which do: config DEBUG_MUTEXES bool "Mutex debugging, basic checks" config DEBUG_LOCK_ALLOC bool "Detect incorrect freeing of live mutexes" Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- init/main.c | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'init/main.c') diff --git a/init/main.c b/init/main.c index d604dfef82b8..fc73e1cd8614 100644 --- a/init/main.c +++ b/init/main.c @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -511,6 +512,13 @@ asmlinkage void __init start_kernel(void) console_init(); if (panic_later) panic(panic_later, panic_param); + /* + * Need to run this when irqs are enabled, because it wants + * to self-test [hard/soft]-irqs on/off lock inversion bugs + * too: + */ + locking_selftest(); + #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start && !initrd_below_start_ok && initrd_start < min_low_pfn << PAGE_SHIFT) { -- cgit v1.2.2 From fbb9ce9530fd9b66096d5187fa6a115d16d9746c Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Mon, 3 Jul 2006 00:24:50 -0700 Subject: [PATCH] lockdep: core Do 'make oldconfig' and accept all the defaults for new config options - reboot into the kernel and if everything goes well it should boot up fine and you should have /proc/lockdep and /proc/lockdep_stats files. Typically if the lock validator finds some problem it will print out voluminous debug output that begins with "BUG: ..." and which syslog output can be used by kernel developers to figure out the precise locking scenario. What does the lock validator do? It "observes" and maps all locking rules as they occur dynamically (as triggered by the kernel's natural use of spinlocks, rwlocks, mutexes and rwsems). Whenever the lock validator subsystem detects a new locking scenario, it validates this new rule against the existing set of rules. If this new rule is consistent with the existing set of rules then the new rule is added transparently and the kernel continues as normal. If the new rule could create a deadlock scenario then this condition is printed out. When determining validity of locking, all possible "deadlock scenarios" are considered: assuming arbitrary number of CPUs, arbitrary irq context and task context constellations, running arbitrary combinations of all the existing locking scenarios. In a typical system this means millions of separate scenarios. This is why we call it a "locking correctness" validator - for all rules that are observed the lock validator proves it with mathematical certainty that a deadlock could not occur (assuming that the lock validator implementation itself is correct and its internal data structures are not corrupted by some other kernel subsystem). [see more details and conditionals of this statement in include/linux/lockdep.h and Documentation/lockdep-design.txt] Furthermore, this "all possible scenarios" property of the validator also enables the finding of complex, highly unlikely multi-CPU multi-context races via single single-context rules, increasing the likelyhood of finding bugs drastically. In practical terms: the lock validator already found a bug in the upstream kernel that could only occur on systems with 3 or more CPUs, and which needed 3 very unlikely code sequences to occur at once on the 3 CPUs. That bug was found and reported on a single-CPU system (!). So in essence a race will be found "piecemail-wise", triggering all the necessary components for the race, without having to reproduce the race scenario itself! In its short existence the lock validator found and reported many bugs before they actually caused a real deadlock. To further increase the efficiency of the validator, the mapping is not per "lock instance", but per "lock-class". For example, all struct inode objects in the kernel have inode->inotify_mutex. If there are 10,000 inodes cached, then there are 10,000 lock objects. But ->inotify_mutex is a single "lock type", and all locking activities that occur against ->inotify_mutex are "unified" into this single lock-class. The advantage of the lock-class approach is that all historical ->inotify_mutex uses are mapped into a single (and as narrow as possible) set of locking rules - regardless of how many different tasks or inode structures it took to build this set of rules. The set of rules persist during the lifetime of the kernel. To see the rough magnitude of checking that the lock validator does, here's a portion of /proc/lockdep_stats, fresh after bootup: lock-classes: 694 [max: 2048] direct dependencies: 1598 [max: 8192] indirect dependencies: 17896 all direct dependencies: 16206 dependency chains: 1910 [max: 8192] in-hardirq chains: 17 in-softirq chains: 105 in-process chains: 1065 stack-trace entries: 38761 [max: 131072] combined max dependencies: 2033928 hardirq-safe locks: 24 hardirq-unsafe locks: 176 softirq-safe locks: 53 softirq-unsafe locks: 137 irq-safe locks: 59 irq-unsafe locks: 176 The lock validator has observed 1598 actual single-thread locking patterns, and has validated all possible 2033928 distinct locking scenarios. More details about the design of the lock validator can be found in Documentation/lockdep-design.txt, which can also found at: http://redhat.com/~mingo/lockdep-patches/lockdep-design.txt [bunk@stusta.de: cleanups] Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- init/main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'init/main.c') diff --git a/init/main.c b/init/main.c index fc73e1cd8614..fc473d4b56fd 100644 --- a/init/main.c +++ b/init/main.c @@ -48,6 +48,7 @@ #include #include #include +#include #include #include @@ -457,6 +458,15 @@ asmlinkage void __init start_kernel(void) smp_setup_processor_id(); + /* + * Need to run as early as possible, to initialize the + * lockdep hash: + */ + lockdep_init(); + + local_irq_disable(); + early_boot_irqs_off(); + /* * Interrupts are still disabled. Do necessary setups, then * enable them @@ -502,6 +512,7 @@ asmlinkage void __init start_kernel(void) profile_init(); if (!irqs_disabled()) printk("start_kernel(): bug: interrupts were enabled early\n"); + early_boot_irqs_on(); local_irq_enable(); /* @@ -512,6 +523,9 @@ asmlinkage void __init start_kernel(void) console_init(); if (panic_later) panic(panic_later, panic_param); + + lockdep_info(); + /* * Need to run this when irqs are enabled, because it wants * to self-test [hard/soft]-irqs on/off lock inversion bugs -- cgit v1.2.2 From 243c7621aac4ed1aa79524c9a1cecf7c05a28124 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Mon, 3 Jul 2006 00:25:06 -0700 Subject: [PATCH] lockdep: annotate genirq Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- init/main.c | 1 + 1 file changed, 1 insertion(+) (limited to 'init/main.c') diff --git a/init/main.c b/init/main.c index fc473d4b56fd..628b8e9e841a 100644 --- a/init/main.c +++ b/init/main.c @@ -466,6 +466,7 @@ asmlinkage void __init start_kernel(void) local_irq_disable(); early_boot_irqs_off(); + early_init_irq_lock_class(); /* * Interrupts are still disabled. Do necessary setups, then -- cgit v1.2.2