Messages in this thread | | | Date | Thu, 6 Sep 2018 10:17:01 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH] lockdep: Have assert functions test for actual interrupts disabled |
| |
On Thu, 6 Sep 2018 15:52:58 +0200 Peter Zijlstra <peterz@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
| |