Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754266AbYKFH6Q (ORCPT ); Thu, 6 Nov 2008 02:58:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752963AbYKFH6A (ORCPT ); Thu, 6 Nov 2008 02:58:00 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:38321 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752942AbYKFH6A (ORCPT ); Thu, 6 Nov 2008 02:58:00 -0500 Date: Thu, 6 Nov 2008 08:57:54 +0100 From: Ingo Molnar To: Zdenek Kabelac Cc: Linux Kernel Mailing List , Peter Zijlstra , Steven Rostedt Subject: Re: sys_sched_yield keeps locked irq before call of schedule() Message-ID: <20081106075754.GE8459@elte.hu> References: <20081105130113.GB29548@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00,DNS_FROM_SECURITYSAGE autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 DNS_FROM_SECURITYSAGE RBL: Envelope sender in blackholes.securitysage.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1453 Lines: 39 * Zdenek Kabelac wrote: > > is this some special warning you added? The stock kernel certainly > > does not emit this warning. > > Yes - it's my personal debug checker that tries to watch wether irq > & irqsafe are running in pair. So it shows a warning if there is a > call of spin_lock_irq and irq is already dissabled. btw., i have added lockdep instrumentation for this two years ago, it's in the upstream kernel: /proc/lockdep_stats: redundant hardirq ons: 7744 /proc/lockdep_stats: redundant hardirq offs: 1873736 /proc/lockdep_stats: redundant softirq ons: 0 /proc/lockdep_stats: redundant softirq offs: 0 you could extend the code to trace it. See kernel/lockdep.c:trace_hardirqs_on_caller(). This bit does it: if (unlikely(curr->hardirqs_enabled)) { debug_atomic_inc(&redundant_hardirqs_on); return; } you could add a ftrace_printk("redundant hardirq") call right there, enable ftrace, and enable stack tracing of each trace entry: echo stacktrace > /debug/tracing/iter_ctrl then you should see all the call sites in /debug/tracing/trace. Ingo -- 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/