From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756876Ab1GAQCU (ORCPT ); Fri, 1 Jul 2011 12:02:20 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:59056 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788Ab1GAQCP (ORCPT ); Fri, 1 Jul 2011 12:02:15 -0400 Date: Fri, 1 Jul 2011 18:02:10 +0200 From: Frederic Weisbecker To: Ingo Molnar Cc: LKML , "Paul E. McKenney" , Peter Zijlstra , Randy Dunlap , Thomas Gleixner Subject: Re: [GIT PULL v2] sched: Make sleep inside atomic detection work on !PREEMPT Message-ID: <20110701160207.GF8508@somewhere> References: <1307712622-11104-1-git-send-email-fweisbec@gmail.com> <20110622224844.GA3290@somewhere> <20110701123629.GA12605@elte.hu> <20110701125644.GD8508@somewhere> <20110701125926.GF12605@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110701125926.GF12605@elte.hu> 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 On Fri, Jul 01, 2011 at 02:59:26PM +0200, Ingo Molnar wrote: > > * Frederic Weisbecker wrote: > > > On Fri, Jul 01, 2011 at 02:36:29PM +0200, Ingo Molnar wrote: > > > > > > * Frederic Weisbecker wrote: > > > > > > > On Fri, Jun 10, 2011 at 03:30:18PM +0200, Frederic Weisbecker wrote: > > > > > Ingo, > > > > > > > > > > Please pull the sched/core branch that can be found at: > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git > > > > > sched/core > > > > > > > > Hi Ingo, > > > > > > > > I have added Randy's ack on the last patch. To get it, please pull the v2 in > > > > the following branch: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git > > > > sched/core-v2 > > > > > > > > There are no other changes. > > > > > > Hm, this triggers such warnings now: > > > > > > Detected 2010.217 MHz processor. > > > Marking TSC unstable due to TSCs unsynchronized > > > Calibrating delay loop (skipped), value calculated using timer frequency.. 4022.95 BogoMIPS (lpj=6700723) > > > pid_max: default: 4096 minimum: 301 > > > BUG: scheduling while atomic: swapper/0/0x10000002 > > > no locks held by swapper/0. > > > Pid: 0, comm: swapper Not tainted 3.0.0-rc5-tip-01401-ga7adf5f-dirty #141020 > > > Call Trace: > > > [] __schedule_bug+0x60/0x65 > > > [] schedule+0x953/0x980 > > > [] ? serial8250_console_putchar+0x30/0x40 > > > [] ? _raw_spin_unlock+0x2b/0x50 > > > [] __cond_resched+0x2a/0x40 > > > [] _cond_resched+0x32/0x40 > > > [] __alloc_pages_nodemask+0x1b8/0x880 > > > [] ? common_interrupt+0xe/0x13 > > > [] ? vprintk+0x359/0x530 > > > [] slob_new_pages+0x17/0x80 > > > [] __kmalloc_node+0xa3/0x270 > > > [] ? printk+0x41/0x43 > > > [] pidmap_init+0x80/0xbf > > > [] start_kernel+0x28b/0x300 > > > [] x86_64_start_reservations+0xfe/0x102 > > > [] x86_64_start_kernel+0xf0/0xf7 > > > Security Framework initialized > > > AppArmor: AppArmor initialized > > > Mount-cache hash table entries: 256 > > > Initializing cgroup subsys cpuacct > > > > > > Not sure we want to warn about schedule during early init, or can > > > it cause problems and should thus be fixed? I bet there's more > > > such instances. > > > > I believe this is harmless because no other other tasks than init > > are queued at that time. But I don't know, may be calling > > schedule() involves some things that are not ready yet at that > > time. > > So why does it have need_resched set then? (which i presume must be a > condition for cond_resched() to call into schedule()) Good point, I'm looking at this. > > Either we add a system_state check in schedule_debug() or we fix > > the callers to not call schedule when system_state shows we are > > booting.. > > Hm, such attempts were rather fragile in the past. > > Thanks, > > Ingo