more lockdep-RCU and RCU_FAST_NO_HZ fixes
in [Kernel]
|
Prev: syscalls: add new COMPAT_SYSCALL_DEFINE#N() macro
Next: atang tree: make SATA Asynchronous Notification work
From: Paul E. McKenney on 28 Feb 2010 11:40 On Sun, Feb 28, 2010 at 09:55:05AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> wrote: > > > Hello! > > > > This series (1) makes RCU_FAST_NO_HZ actually do the full number of > > iterations specified instead of just one and (2) fixes an RCU lockdep > > splat. > > Thanks, applied. > > This one is pretty stubborn, it still triggers: > > [ 0.000000] soft-irq read-recursion/321: ok | > [ 0.000000] ------------------------------------------------------- > [ 0.000000] Good, all 218 testcases passed! | > [ 0.000000] --------------------------------- > [ 0.000000] allocated 10485760 bytes of page_cgroup > [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups > [ 0.000000] > [ 0.000000] =================================================== > [ 0.000000] [ INFO: suspicious rcu_dereference_check() usage. ] > [ 0.000000] --------------------------------------------------- > [ 0.000000] kernel/sched_fair.c:3479 invoked rcu_dereference_check() without protection! > [ 0.000000] > [ 0.000000] other info that might help us debug this: > [ 0.000000] > [ 0.000000] no locks held by swapper/0. > [ 0.000000] > [ 0.000000] stack backtrace: > [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.33-tip-01015-g97e7da3-dirty #10753 > [ 0.000000] Call Trace: > [ 0.000000] <IRQ> [<ffffffff8107f5d1>] lockdep_rcu_dereference+0xa1/0xb0 > [ 0.000000] [<ffffffff8104afd1>] scheduler_tick+0x221/0x2c0 > [ 0.000000] [<ffffffff8105f6d5>] update_process_times+0x55/0x70 > [ 0.000000] [<ffffffff8107ac27>] tick_periodic+0x27/0x70 > [ 0.000000] [<ffffffff8107ac8f>] tick_handle_periodic+0x1f/0x90 > [ 0.000000] [<ffffffff8100e29a>] timer_interrupt+0x1a/0x30 > [ 0.000000] [<ffffffff810a28aa>] handle_IRQ_event+0x3a/0xe0 > [ 0.000000] [<ffffffff810a53ab>] handle_level_irq+0x8b/0x130 > [ 0.000000] [<ffffffff8100da94>] handle_irq+0x44/0x70 > [ 0.000000] [<ffffffff8100cfde>] do_IRQ+0x6e/0xf0 > [ 0.000000] [<ffffffff817eea13>] ret_from_intr+0x0/0x16 > [ 0.000000] <EOI> [<ffffffff8102dfe6>] ? native_restore_fl+0x6/0x10 > [ 0.000000] [<ffffffff817ee3df>] _raw_spin_unlock_irqrestore+0x6f/0x80 > [ 0.000000] [<ffffffff810a37f3>] __setup_irq+0x1b3/0x3b0 > [ 0.000000] [<ffffffff810a3a18>] setup_irq+0x28/0x40 > [ 0.000000] [<ffffffff81ef2914>] setup_default_timer_irq+0x12/0x14 > [ 0.000000] [<ffffffff81ef292d>] hpet_time_init+0x17/0x19 > [ 0.000000] [<ffffffff81ef28fb>] x86_late_time_init+0xa/0x11 > [ 0.000000] [<ffffffff81eefcf4>] start_kernel+0x25f/0x2e6 > [ 0.000000] [<ffffffff81eef30b>] x86_64_start_reservations+0xf6/0xfa > [ 0.000000] [<ffffffff81eef409>] x86_64_start_kernel+0xfa/0x109 > [ 0.000000] Fast TSC calibration using PIT > [ 0.000000] Detected 2002.507 MHz processor. > [ 0.004004] Calibrating delay loop (skipped), value calculated using timer frequency.. 4005.01 BogoMIPS (lpj=2002507) Ah -- this is a new arrival from my viewpoint. Patch below! This won't apply to tip/core/rcu, but does against current tip/master. Thanx, Paul ------------------------------------------------------------------------ sched: fix rcu_dereference() for RCU-lockde Make rcu_dereference() of runqueue data structures be rcu_dereference_sched(). Located-by: Ingo Molnar <mingo(a)elte.hu> Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> --- sched_fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c index 3e1fd96..5a5ea2c 100644 --- a/kernel/sched_fair.c +++ b/kernel/sched_fair.c @@ -3476,7 +3476,7 @@ static void run_rebalance_domains(struct softirq_action *h) static inline int on_null_domain(int cpu) { - return !rcu_dereference(cpu_rq(cpu)->sd); + return !rcu_dereference_sched(cpu_rq(cpu)->sd); } /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 1 Mar 2010 11:10 On Mon, Mar 01, 2010 at 01:10:45PM +0100, Ingo Molnar wrote: > > FYI, even with your patch applied i'm getting this in -tip testing: > > [ 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 > > Config attached. > > The sha1 is: > > b5fabe1: Merge branch 'perf/urgent' > > i.e. your latest fix is included: > > 90a6501: sched, rcu: Fix rcu_dereference() for RCU-lockdep Sigh! I clearly need a more organized approach for handling this very early boot stuff. Fix is in progress, please accept my apologies for the hassle! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 1 Mar 2010 14:00
On Mon, Mar 01, 2010 at 06:58:10PM +0100, Peter Zijlstra wrote: > On Mon, 2010-03-01 at 08:08 -0800, Paul E. McKenney wrote: > > On Mon, Mar 01, 2010 at 01:10:45PM +0100, Ingo Molnar wrote: > > > > > > FYI, even with your patch applied i'm getting this in -tip testing: > > > > > > [ 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 > > > > > > Config attached. > > > > > > The sha1 is: > > > > > > b5fabe1: Merge branch 'perf/urgent' > > > > > > i.e. your latest fix is included: > > > > > > 90a6501: sched, rcu: Fix rcu_dereference() for RCU-lockdep > > > > Sigh! I clearly need a more organized approach for handling this very > > early boot stuff. Fix is in progress, please accept my apologies for > > the hassle! > > add: system_state != SYSTEM_RUNNING, to all the default > rcu_read_lock*_held thingies? My current thought is !rcu_scheduler active to rcu_read_lock*_held() and to rcu_dereference_check(), but yes, that is pretty much the approach that I am taking. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |