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