2005-04-17 06:20:36 +08:00
|
|
|
#ifndef LINUX_HARDIRQ_H
|
|
|
|
|
#define LINUX_HARDIRQ_H
|
|
|
|
|
|
2005-07-13 04:58:36 +08:00
|
|
|
#include <linux/preempt.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/smp_lock.h>
|
[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 <mingo@elte.hu>
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 15:24:50 +08:00
|
|
|
#include <linux/lockdep.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/hardirq.h>
|
|
|
|
|
#include <asm/system.h>
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We put the hardirq and softirq counter into the preemption
|
|
|
|
|
* counter. The bitmask has the following meaning:
|
|
|
|
|
*
|
|
|
|
|
* - bits 0-7 are the preemption count (max preemption depth: 256)
|
|
|
|
|
* - bits 8-15 are the softirq count (max # of softirqs: 256)
|
|
|
|
|
*
|
|
|
|
|
* The hardirq count can be overridden per architecture, the default is:
|
|
|
|
|
*
|
|
|
|
|
* - bits 16-27 are the hardirq count (max # of hardirqs: 4096)
|
|
|
|
|
* - ( bit 28 is the PREEMPT_ACTIVE flag. )
|
|
|
|
|
*
|
|
|
|
|
* PREEMPT_MASK: 0x000000ff
|
|
|
|
|
* SOFTIRQ_MASK: 0x0000ff00
|
|
|
|
|
* HARDIRQ_MASK: 0x0fff0000
|
|
|
|
|
*/
|
|
|
|
|
#define PREEMPT_BITS 8
|
|
|
|
|
#define SOFTIRQ_BITS 8
|
|
|
|
|
|
|
|
|
|
#ifndef HARDIRQ_BITS
|
|
|
|
|
#define HARDIRQ_BITS 12
|
2006-10-04 17:16:49 +08:00
|
|
|
|
|
|
|
|
#ifndef MAX_HARDIRQS_PER_CPU
|
|
|
|
|
#define MAX_HARDIRQS_PER_CPU NR_IRQS
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* The hardirq mask has to be large enough to have space for potentially
|
|
|
|
|
* all IRQ sources in the system nesting on a single CPU.
|
|
|
|
|
*/
|
2006-10-04 17:16:49 +08:00
|
|
|
#if (1 << HARDIRQ_BITS) < MAX_HARDIRQS_PER_CPU
|
2005-04-17 06:20:36 +08:00
|
|
|
# error HARDIRQ_BITS is too low!
|
|
|
|
|
#endif
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#define PREEMPT_SHIFT 0
|
|
|
|
|
#define SOFTIRQ_SHIFT (PREEMPT_SHIFT + PREEMPT_BITS)
|
|
|
|
|
#define HARDIRQ_SHIFT (SOFTIRQ_SHIFT + SOFTIRQ_BITS)
|
|
|
|
|
|
|
|
|
|
#define __IRQ_MASK(x) ((1UL << (x))-1)
|
|
|
|
|
|
|
|
|
|
#define PREEMPT_MASK (__IRQ_MASK(PREEMPT_BITS) << PREEMPT_SHIFT)
|
|
|
|
|
#define SOFTIRQ_MASK (__IRQ_MASK(SOFTIRQ_BITS) << SOFTIRQ_SHIFT)
|
2005-05-29 06:52:02 +08:00
|
|
|
#define HARDIRQ_MASK (__IRQ_MASK(HARDIRQ_BITS) << HARDIRQ_SHIFT)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#define PREEMPT_OFFSET (1UL << PREEMPT_SHIFT)
|
|
|
|
|
#define SOFTIRQ_OFFSET (1UL << SOFTIRQ_SHIFT)
|
|
|
|
|
#define HARDIRQ_OFFSET (1UL << HARDIRQ_SHIFT)
|
|
|
|
|
|
2005-05-29 06:52:02 +08:00
|
|
|
#if PREEMPT_ACTIVE < (1 << (HARDIRQ_SHIFT + HARDIRQ_BITS))
|
|
|
|
|
#error PREEMPT_ACTIVE is too low!
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define hardirq_count() (preempt_count() & HARDIRQ_MASK)
|
|
|
|
|
#define softirq_count() (preempt_count() & SOFTIRQ_MASK)
|
|
|
|
|
#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK))
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Are we doing bottom half or hardware interrupt processing?
|
|
|
|
|
* Are we in a softirq context? Interrupt context?
|
|
|
|
|
*/
|
|
|
|
|
#define in_irq() (hardirq_count())
|
|
|
|
|
#define in_softirq() (softirq_count())
|
|
|
|
|
#define in_interrupt() (irq_count())
|
|
|
|
|
|
|
|
|
|
#if defined(CONFIG_PREEMPT) && !defined(CONFIG_PREEMPT_BKL)
|
|
|
|
|
# define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != kernel_locked())
|
|
|
|
|
#else
|
|
|
|
|
# define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != 0)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PREEMPT
|
|
|
|
|
# define preemptible() (preempt_count() == 0 && !irqs_disabled())
|
|
|
|
|
# define IRQ_EXIT_OFFSET (HARDIRQ_OFFSET-1)
|
|
|
|
|
#else
|
|
|
|
|
# define preemptible() 0
|
|
|
|
|
# define IRQ_EXIT_OFFSET HARDIRQ_OFFSET
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
|
extern void synchronize_irq(unsigned int irq);
|
|
|
|
|
#else
|
|
|
|
|
# define synchronize_irq(irq) barrier()
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-11-14 08:06:57 +08:00
|
|
|
struct task_struct;
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifndef CONFIG_VIRT_CPU_ACCOUNTING
|
|
|
|
|
static inline void account_system_vtime(struct task_struct *tsk)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2006-07-03 15:24:42 +08:00
|
|
|
/*
|
|
|
|
|
* It is safe to do non-atomic ops on ->hardirq_context,
|
|
|
|
|
* because NMI handlers may not preempt and the ops are
|
|
|
|
|
* always balanced, so the interrupted value of ->hardirq_context
|
|
|
|
|
* will always be restored.
|
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
#define irq_enter() \
|
|
|
|
|
do { \
|
|
|
|
|
account_system_vtime(current); \
|
|
|
|
|
add_preempt_count(HARDIRQ_OFFSET); \
|
2006-07-03 15:24:42 +08:00
|
|
|
trace_hardirq_enter(); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Exit irq context without processing softirqs:
|
|
|
|
|
*/
|
|
|
|
|
#define __irq_exit() \
|
|
|
|
|
do { \
|
|
|
|
|
trace_hardirq_exit(); \
|
|
|
|
|
account_system_vtime(current); \
|
|
|
|
|
sub_preempt_count(HARDIRQ_OFFSET); \
|
2005-04-17 06:20:36 +08:00
|
|
|
} while (0)
|
|
|
|
|
|
2006-07-03 15:24:42 +08:00
|
|
|
/*
|
|
|
|
|
* Exit irq context and process softirqs if needed:
|
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
extern void irq_exit(void);
|
|
|
|
|
|
[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 <mingo@elte.hu>
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 15:24:50 +08:00
|
|
|
#define nmi_enter() do { lockdep_off(); irq_enter(); } while (0)
|
|
|
|
|
#define nmi_exit() do { __irq_exit(); lockdep_on(); } while (0)
|
2006-07-03 15:24:42 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* LINUX_HARDIRQ_H */
|
