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