Commit | Line | Data |
---|---|---|
b4282c79 | 1 | ======================= |
55df314f | 2 | IRQ-flags state tracing |
b4282c79 | 3 | ======================= |
55df314f | 4 | |
b4282c79 | 5 | :Author: started by Ingo Molnar <mingo@redhat.com> |
55df314f | 6 | |
b4282c79 | 7 | The "irq-flags tracing" feature "traces" hardirq and softirq state, in |
55df314f IM |
8 | that it gives interested subsystems an opportunity to be notified of |
9 | every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that | |
10 | happens in the kernel. | |
11 | ||
12 | CONFIG_TRACE_IRQFLAGS_SUPPORT is needed for CONFIG_PROVE_SPIN_LOCKING | |
13 | and CONFIG_PROVE_RW_LOCKING to be offered by the generic lock debugging | |
14 | code. Otherwise only CONFIG_PROVE_MUTEX_LOCKING and | |
15 | CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these | |
16 | are locking APIs that are not used in IRQ context. (the one exception | |
17 | for rwsems is worked around) | |
18 | ||
b4282c79 | 19 | Architecture support for this is certainly not in the "trivial" |
55df314f IM |
20 | category, because lots of lowlevel assembly code deal with irq-flags |
21 | state changes. But an architecture can be irq-flags-tracing enabled in a | |
22 | rather straightforward and risk-free manner. | |
23 | ||
24 | Architectures that want to support this need to do a couple of | |
25 | code-organizational changes first: | |
26 | ||
55df314f IM |
27 | - add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file |
28 | ||
29 | and then a couple of functional changes are needed as well to implement | |
30 | irq-flags-tracing support: | |
31 | ||
32 | - in lowlevel entry code add (build-conditional) calls to the | |
33 | trace_hardirqs_off()/trace_hardirqs_on() functions. The lock validator | |
34 | closely guards whether the 'real' irq-flags matches the 'virtual' | |
35 | irq-flags state, and complains loudly (and turns itself off) if the | |
36 | two do not match. Usually most of the time for arch support for | |
37 | irq-flags-tracing is spent in this state: look at the lockdep | |
38 | complaint, try to figure out the assembly code we did not cover yet, | |
39 | fix and repeat. Once the system has booted up and works without a | |
40 | lockdep complaint in the irq-flags-tracing functions arch support is | |
41 | complete. | |
42 | - if the architecture has non-maskable interrupts then those need to be | |
43 | excluded from the irq-tracing [and lock validation] mechanism via | |
44 | lockdep_off()/lockdep_on(). | |
45 | ||
b4282c79 | 46 | In general there is no risk from having an incomplete irq-flags-tracing |
55df314f IM |
47 | implementation in an architecture: lockdep will detect that and will |
48 | turn itself off. I.e. the lock validator will still be reliable. There | |
49 | should be no crashes due to irq-tracing bugs. (except if the assembly | |
50 | changes break other code by modifying conditions or registers that | |
25985edc | 51 | shouldn't be) |
55df314f | 52 |