On Tue, Mar 12, 2019 at 08:20:34AM -0700, Paul E. McKenney wrote: [snip] > > > Could we be more explicit in the code that this function can only > > be called from an interrupt, and also we change the code comment to be more > > clear about it (like the following diff)? > > That would be good! > > Nice trick on using dyntick state to check for interrupt nesting, but > wouldn't consolidating the counters break that? But is there a lockdep > check for being in a hardware interrupt handler? If not, could one > be added? This would have the benefit of not adding overhead to the > scheduling-clock interrupt in production builds of the Linux kernel, > while still finding this bug in testing. > > (Another approach would be to use IS_ENABLED(CONFIG_PROVE_RCU), but > a lockdep check would be cleaner.) AFAICS, lockdep does not specifically track when we enter an interrupt, but rather only tracks when interrupts are enabled/disabled. But we could use in_irq() to find if we are in an interrupt (which uses the preempt_count to track in HARDIRQ_MASK section of the counter). I will add an in_irq() check that does the check only when PROVE_RCU is enabled, and send a patch. Thanks and it is my pleasure to look into this, quite interesting! - Joel
