From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Randy Dunlap <randy.dunlap@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [GIT PULL v2] sched: Make sleep inside atomic detection work on !PREEMPT
Date: Fri, 1 Jul 2011 14:56:46 +0200 [thread overview]
Message-ID: <20110701125644.GD8508@somewhere> (raw)
In-Reply-To: <20110701123629.GA12605@elte.hu>
On Fri, Jul 01, 2011 at 02:36:29PM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@gmail.com> 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:
> [<ffffffff81ddb3b0>] __schedule_bug+0x60/0x65
> [<ffffffff81dee803>] schedule+0x953/0x980
> [<ffffffff81571e30>] ? serial8250_console_putchar+0x30/0x40
> [<ffffffff81df177b>] ? _raw_spin_unlock+0x2b/0x50
> [<ffffffff8107882a>] __cond_resched+0x2a/0x40
> [<ffffffff81dee8e2>] _cond_resched+0x32/0x40
> [<ffffffff81110ba8>] __alloc_pages_nodemask+0x1b8/0x880
> [<ffffffff81df23ce>] ? common_interrupt+0xe/0x13
> [<ffffffff81080649>] ? vprintk+0x359/0x530
> [<ffffffff8113b4e7>] slob_new_pages+0x17/0x80
> [<ffffffff8113bd13>] __kmalloc_node+0xa3/0x270
> [<ffffffff81ddb6d5>] ? printk+0x41/0x43
> [<ffffffff82738420>] pidmap_init+0x80/0xbf
> [<ffffffff8272aa54>] start_kernel+0x28b/0x300
> [<ffffffff8272a2ee>] x86_64_start_reservations+0xfe/0x102
> [<ffffffff8272a3e2>] 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.
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..
next prev parent reply other threads:[~2011-07-01 12:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-10 13:30 [GIT PULL] sched: Make sleep inside atomic detection work on !PREEMPT Frederic Weisbecker
2011-06-10 13:30 ` [PATCH 1/4] sched: Remove pointless in_atomic() definition check Frederic Weisbecker
2011-06-10 13:30 ` [PATCH 2/4] sched: Isolate preempt counting in its own config option Frederic Weisbecker
2011-06-10 13:30 ` [PATCH 3/4] sched: Make sleeping inside spinlock detection working in !CONFIG_PREEMPT Frederic Weisbecker
2011-06-10 13:30 ` [PATCH 4/4] sched: Generalize sleep inside spinlock detection Frederic Weisbecker
2011-06-10 15:37 ` Randy Dunlap
2011-06-23 4:19 ` KOSAKI Motohiro
2011-06-22 22:48 ` [GIT PULL v2] sched: Make sleep inside atomic detection work on !PREEMPT Frederic Weisbecker
2011-07-01 12:36 ` Ingo Molnar
2011-07-01 12:56 ` Frederic Weisbecker [this message]
2011-07-01 12:59 ` Ingo Molnar
2011-07-01 15:05 ` Ingo Molnar
2011-07-01 16:01 ` Frederic Weisbecker
2011-07-01 16:44 ` Frederic Weisbecker
2011-07-01 17:29 ` Ingo Molnar
2011-07-02 16:53 ` Frederic Weisbecker
2011-07-03 19:49 ` Ingo Molnar
2011-07-01 16:02 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110701125644.GD8508@somewhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=randy.dunlap@oracle.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox