linux-kernel - Re: [PATCH] percpu: use raw_local_irq_* in _this

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120214074035.GA18994@zhy>
Date:	Tue, 14 Feb 2012 15:40:36 +0800
From:	Yong Zhang <yong.zhang0@...il.com>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] percpu: use raw_local_irq_* in _this_cpu op

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@...nel.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);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/