public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yong Zhang <yong.zhang0@gmail.com>
To: Ming Lei <tom.leiming@gmail.com>
Cc: Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] percpu: use raw_local_irq_* in _this_cpu op
Date: Tue, 14 Feb 2012 15:40:36 +0800	[thread overview]
Message-ID: <20120214074035.GA18994@zhy> (raw)
In-Reply-To: <CACVXFVMyihmG3NexXOqTUoJb8UJFa7dJqYGOr6oC_y5heFSo1A@mail.gmail.com>

On Tue, Feb 14, 2012 at 11:30:06AM +0800, Ming Lei wrote:
> Hi,
> 
> On Tue, Feb 14, 2012 at 1:23 AM, Tejun Heo <tj@kernel.org> wrote:
> > On Mon, Feb 13, 2012 at 07:03:38PM +0800, Ming Lei wrote:
> >> It doesn't make sense to trace irq off or do irq flags
> >> lock proving inside 'this_cpu' operations, so replace local_irq_*
> >> with raw_local_irq_* in 'this_cpu' op.
> >>
> >> Also the patch fixes one lockdep warning[1], which is caused
> >> by the added local_irq_save/restore(flags) in this_cpu_inc
> >> called by __debug_atomic_inc: kernel/lockdep.c
> >
> > I think this isn't gonna hurt anything but I don't understand why the
> > lockdep warning is triggering when using traced version. ?Can you
> > please explain that in a bit more detail in the patch description?
> 
> In trace_hardirqs_on_caller:kernel/lockdep.c, __debug_atomic_inc
> will be called to add on 'this_cpu' variable, so may introduce recursive
> trace_hardirqs_on|off_caller called.

Don't we need to prevent this kind of recursion first?

UNTESTED patch, I guess it'll smooth your concern.
---
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 8889f7d..028b4c5 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2561,6 +2561,8 @@ void trace_hardirqs_on_caller(unsigned long ip)
 	if (unlikely(!debug_locks || current->lockdep_recursion))
 		return;
 
+	current->lockdep_recursion = 1;
+
 	if (unlikely(current->hardirqs_enabled)) {
 		/*
 		 * Neither irq nor preemption are disabled here
@@ -2568,7 +2570,7 @@ void trace_hardirqs_on_caller(unsigned long ip)
 		 * in a stat is not a big deal.
 		 */
 		__debug_atomic_inc(redundant_hardirqs_on);
-		return;
+		goto out;
 	}
 
 	/*
@@ -2577,23 +2579,24 @@ void trace_hardirqs_on_caller(unsigned long ip)
 	 * enabled.. someone messed up their IRQ state tracing.
 	 */
 	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
-		return;
+		goto out;
 
 	/*
 	 * See the fine text that goes along with this variable definition.
 	 */
 	if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
-		return;
+		goto out;
 
 	/*
 	 * Can't allow enabling interrupts while in an interrupt handler,
 	 * that's general bad form and such. Recursion, limited stack etc..
 	 */
 	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
-		return;
+		goto out;
 
-	current->lockdep_recursion = 1;
 	__trace_hardirqs_on_caller(ip);
+
+out:
 	current->lockdep_recursion = 0;
 }
 EXPORT_SYMBOL(trace_hardirqs_on_caller);

  reply	other threads:[~2012-02-14  7:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-13 11:03 [PATCH] percpu: use raw_local_irq_* in _this_cpu op Ming Lei
2012-02-13 14:59 ` Christoph Lameter
2012-02-13 17:23 ` Tejun Heo
2012-02-14  3:30   ` Ming Lei
2012-02-14  7:40     ` Yong Zhang [this message]
2012-02-14 14:53       ` Ming Lei
2012-02-14 16:19     ` Tejun Heo

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=20120214074035.GA18994@zhy \
    --to=yong.zhang0@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=tom.leiming@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox