Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759396Ab2BNHkv (ORCPT ); Tue, 14 Feb 2012 02:40:51 -0500 Received: from mail-qy0-f174.google.com ([209.85.216.174]:47017 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754324Ab2BNHku (ORCPT ); Tue, 14 Feb 2012 02:40:50 -0500 Date: Tue, 14 Feb 2012 15:40:36 +0800 From: Yong Zhang To: Ming Lei Cc: Tejun Heo , Christoph Lameter , Peter Zijlstra , linux-kernel@vger.kernel.org Subject: Re: [PATCH] percpu: use raw_local_irq_* in _this_cpu op Message-ID: <20120214074035.GA18994@zhy> Reply-To: Yong Zhang References: <1329131018-19107-1-git-send-email-tom.leiming@gmail.com> <20120213172311.GB12117@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2678 Lines: 81 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 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); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/