On Thu, 6 Sep 2018 15:52:58 +0200 Peter Zijlstra <pet...@infradead.org> wrote:
> On Wed, Sep 05, 2018 at 11:20:31AM -0400, Steven Rostedt wrote: > > > > Peter, you OK with this patch? I'm currently triggering a bug (in rc2) > > where this patch is telling me that lockdep is getting it wrong. It > > would be good to have this upstream such that we know if it is really a > > bug in the code itself, or if lockdep didn't keep up properly. > > I thought we had something for that under CONFIG_DEBUG_LOCKDEP. > > /me checks and finds: > > kernel/locking/lockdep.c:check_flags() > > Doesn't that work? Perhaps it does, but DEBUG_LOCKDEP wasn't set. Thus, when a use case like this happens it will confuse developers because all they see is: ------------[ cut here ]------------ IRQs not enabled as expected [...] And there's no reason to assume that lockdep is broken. Commits like ebf3adbad012b ("timers/nohz: Use lockdep to assert IRQs are disabled/enabled") which replace WARN_ON_ONCE(!irqs_disabled()) with lockdep_assert_irqs_disabled(), were done for performance reasons (which I agree with). My patch doesn't affect performance as it only does the "irqs_disabled()" check when the WARN_ONCE() actually triggers. And gives useful information. If I haven't worked on lockdep in the past, I would have been spending a lot more time trying to figure out why interrupts were disabled here and never looking into the fact that the report was wrong. I still think checking if IRQS are really disabled or not when lockdep thinks it is (or not) is valuable and doesn't cause any other problems. -- Steve