All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH] lockdep: Have assert functions test for actual interrupts disabled
Date: Thu, 6 Sep 2018 10:17:01 -0400	[thread overview]
Message-ID: <20180906101701.3ffcba07@gandalf.local.home> (raw)
In-Reply-To: <20180906135258.GE24106@hirez.programming.kicks-ass.net>

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


  reply	other threads:[~2018-09-06 14:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07  1:41 [PATCH] lockdep: Have assert functions test for actual interrupts disabled Steven Rostedt
2018-09-05 15:20 ` Steven Rostedt
2018-09-06 13:52   ` Peter Zijlstra
2018-09-06 14:17     ` Steven Rostedt [this message]
2018-09-06 16:43       ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180906101701.3ffcba07@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.