[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100227224859.GB6846@linux.vnet.ibm.com>
Date: Sat, 27 Feb 2010 14:48:59 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org, laijs@...fujitsu.com,
dipankar@...ibm.com, akpm@...ux-foundation.org,
mathieu.desnoyers@...ymtl.ca, josh@...htriplett.org,
dvhltc@...ibm.com, niv@...ibm.com, tglx@...utronix.de,
peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
dhowells@...hat.com
Subject: Re: [PATCH tip/core/rcu 0/2] rcu: fixes for RCU lockdep
On Sat, Feb 27, 2010 at 01:59:53PM +0100, Ingo Molnar wrote:
>
> here's another one:
>
> [ 0.000000] Memory: 914996k/1047744k available (15146k kernel code, 452k absent, 131584k reserved, 12516k data, 2552k init)
> [ 0.000000] SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000]
> [ 0.000000] ===================================================
> [ 0.000000] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 0.000000] ---------------------------------------------------
> [ 0.000000] include/linux/cgroup.h:492 invoked rcu_dereference_check() without protection!
> [ 0.000000]
> [ 0.000000] other info that might help us debug this:
> [ 0.000000]
> [ 0.000000] 1 lock held by swapper/0:
> [ 0.000000] #0: (&rq->lock){......}, at: [<ffffffff81ec0bad>] init_idle+0x31/0x1ee
> [ 0.000000]
> [ 0.000000] stack backtrace:
> [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.33-tip+ #10563
> [ 0.000000] Call Trace:
> [ 0.000000] [<ffffffff810ad1c1>] lockdep_rcu_dereference+0xa1/0xb0
> [ 0.000000] [<ffffffff81ec0cbd>] init_idle+0x141/0x1ee
> [ 0.000000] [<ffffffff82ceff40>] sched_init+0x43a/0x4b6
> [ 0.000000] [<ffffffff82cdcceb>] start_kernel+0x1b3/0x49e
> [ 0.000000] [<ffffffff82cdc319>] x86_64_start_reservations+0x120/0x124
> [ 0.000000] [<ffffffff82cdc46b>] x86_64_start_kernel+0x14e/0x15d
> [ 0.000000] Hierarchical RCU implementation.
> [ 0.000000] RCU-based detection of stalled CPUs is enabled.
> [ 0.000000] NR_IRQS:4352
>
> on:
>
> 1bc9767: Merge branch 'tracing/core'
Thank you very much, found it trivially this time. ;-)
> Config attached. This too seems to a sched-init artifact. Could we use
> inc_preempt_count() perhaps to make sure we have the preempt count disabled
> even on !PREEMPT? Instead of hacking more 'the scheduler is not initialized
> yet' checks into various debug checks?
This is based on plain RCU rather than RCU-sched, so inc_preempt_count()
won't help in this case (though I expect that it might work very well
in other cases). So I hack another 'the scheduler is not initialized
yet' check in a separate set of patches. :-(
Thanx, Paul
--
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/
Powered by blists - more mailing lists