Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760674AbZAGTKd (ORCPT ); Wed, 7 Jan 2009 14:10:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754216AbZAGTKY (ORCPT ); Wed, 7 Jan 2009 14:10:24 -0500 Received: from mu-out-0910.google.com ([209.85.134.189]:23032 "EHLO mu-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752488AbZAGTKX (ORCPT ); Wed, 7 Jan 2009 14:10:23 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TyYP7IrvRl6n41v2UU9mHl5LQMPcr95QPbqXx4SJXtKUqskvPlLU8rL+d8oI/DaR8V xOa59ydzP6+mYcqSXdd7xEvtlZH6TsMp0LNVtZLF8IrgENZOgBTm1ph9Nw+KzOjRcv8b wO3bOZOXrs8ZaH9EK1rC573VROPVNWhGlDbw4= Message-ID: Date: Wed, 7 Jan 2009 22:10:18 +0300 From: "Alexey Zaytsev" To: "Ingo Molnar" Subject: Re: linux-next: Tree for December 11 Cc: "Linus Torvalds" , LKML , "Nick Piggin" , "Peter Zijlstra" In-Reply-To: <20090107184721.GA16193@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081211200459.14d18d7a.sfr@canb.auug.org.au> <20090107171730.GA21799@elte.hu> <20090107184721.GA16193@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2554 Lines: 68 On Wed, Jan 7, 2009 at 21:47, Ingo Molnar wrote: > > * Alexey Zaytsev wrote: > >> And last time I bisected, it pointed to: >> >> commit 7317d7b87edb41a9135e30be1ec3f7ef817c53dd >> Author: Nick Piggin >> Date: Tue Sep 30 20:50:27 2008 +1000 >> >> sched: improve preempt debugging >> >> >> This patch helped me out with a problem I recently had.... >> >> Basically, when the kernel lock is held, then preempt_count >> underflow does not >> get detected until it is released which may be a long time (and arbitrarily, >> eg at different points it may be rescheduled). If the bkl is released at >> schedule, the resulting output is actually fairly cryptic... >> >> With any other lock that elevates preempt_count, it is illegal to schedule >> under it (which would get found pretty quickly). bkl allows scheduling with >> preempt_count elevated, which makes underflows hard to debug. >> >> Signed-off-by: Ingo Molnar >> >> so at least a dumb bisection won't do here. > > ah, sorry for being a slow starter, i missed that bit - merge window > attention span troubles ... > > I think the kernel_locked() check added here is plain buggy against IRQ > contexts: we drop the BKL spinlock and reduce current->kernel_depth > non-atomically. > > So kernel_locked() can become detached from the preempt_count(). > > Nick, can you think of any better way of still saving this debug check, or > should we revert it? > > Although it seems a bit weird how consistently you seem to be able to > trigger it - as this seems to be a narrow race. Is there an IRQ storm > there perhaps, or something widens things up for Qemu to inject an IRQ > right there? I'm not sure about the qemu case, but at least on my laptop it happens somewhere along arch/x86/kernel/cpu/bugs.c: 92 printk(KERN_INFO "Checking 'hlt' instruction... "); 93 if (!boot_cpu_data.hlt_works_ok) { 94 printk("disabled\n"); 95 return; 96 } 97 halt(); 98 halt(); 99 halt(); 100 halt(); 101 printk("OK.\n"); where an interrupt has to come in order to get the cpu from hlt, so there is no surprise that I'm seeing this on every single boot. ;) -- 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/