Merge branches 'bigrt.2012.09.23a', 'doctorture.2012.09.23a',... (bda4ec9f) · Commits · e / devices / android_kernel_fairphone_FP3

Documentation/RCU/checklist.txt

+6 −0

Original line number	Original line	Diff line number	Diff line
	@@ -310,6 +310,12 @@ over a rather long period of time, but improvements are always welcome!
	code under the influence of preempt_disable(), you instead		code under the influence of preempt_disable(), you instead
	need to use synchronize_irq() or synchronize_sched().		need to use synchronize_irq() or synchronize_sched().

			This same limitation also applies to synchronize_rcu_bh()
			and synchronize_srcu(), as well as to the asynchronous and
			expedited forms of the three primitives, namely call_rcu(),
			call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),
			synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().

	12. Any lock acquired by an RCU callback must be acquired elsewhere		12. Any lock acquired by an RCU callback must be acquired elsewhere
	with softirq disabled, e.g., via spin_lock_irqsave(),		with softirq disabled, e.g., via spin_lock_irqsave(),
	spin_lock_bh(), etc. Failing to disable irq on a given		spin_lock_bh(), etc. Failing to disable irq on a given

Documentation/RCU/stallwarn.txt

+8 −8

Original line number	Original line	Diff line number	Diff line
	@@ -99,7 +99,7 @@ In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
	printed:		printed:

	INFO: rcu_preempt detected stall on CPU		INFO: rcu_preempt detected stall on CPU
	0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1		0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
	(t=65000 jiffies)		(t=65000 jiffies)

	The "(64628 ticks this GP)" indicates that this CPU has taken more		The "(64628 ticks this GP)" indicates that this CPU has taken more
	@@ -116,13 +116,13 @@ number between the two "/"s is the value of the nesting, which will
	be a small positive number if in the idle loop and a very large positive		be a small positive number if in the idle loop and a very large positive
	number (as shown above) otherwise.		number (as shown above) otherwise.

	For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the		For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
	CPU is not in the process of trying to force itself into dyntick-idle		not in the process of trying to force itself into dyntick-idle state, the
	state, the "." indicates that the CPU has not given up forcing RCU		"." indicates that the CPU has not given up forcing RCU into dyntick-idle
	into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"		mode (it would be "H" otherwise), and the "timer not pending" indicates
	indicates that the CPU has not recented forced RCU into dyntick-idle		that the CPU has not recently forced RCU into dyntick-idle mode (it
	mode (it would otherwise indicate the number of microseconds remaining		would otherwise indicate the number of microseconds remaining in this
	in this forced state).		forced state).


	Multiple Warnings From One Stall		Multiple Warnings From One Stall

Documentation/RCU/whatisRCU.txt

+7 −2

Original line number	Original line	Diff line number	Diff line
	@@ -873,7 +873,7 @@ d. Do you need to treat NMI handlers, hardirq handlers,
	and code segments with preemption disabled (whether		and code segments with preemption disabled (whether
	via preempt_disable(), local_irq_save(), local_bh_disable(),		via preempt_disable(), local_irq_save(), local_bh_disable(),
	or some other mechanism) as if they were explicit RCU readers?		or some other mechanism) as if they were explicit RCU readers?
	If so, you need RCU-sched.		If so, RCU-sched is the only choice that will work for you.

	e. Do you need RCU grace periods to complete even in the face		e. Do you need RCU grace periods to complete even in the face
	of softirq monopolization of one or more of the CPUs? For		of softirq monopolization of one or more of the CPUs? For
	@@ -884,7 +884,12 @@ f. Is your workload too update-intensive for normal use of
	RCU, but inappropriate for other synchronization mechanisms?		RCU, but inappropriate for other synchronization mechanisms?
	If so, consider SLAB_DESTROY_BY_RCU. But please be careful!		If so, consider SLAB_DESTROY_BY_RCU. But please be careful!

	g. Otherwise, use RCU.		g. Do you need read-side critical sections that are respected
			even though they are in the middle of the idle loop, during
			user-mode execution, or on an offlined CPU? If so, SRCU is the
			only choice that will work for you.

			h. Otherwise, use RCU.

	Of course, this all assumes that you have determined that RCU is in fact		Of course, this all assumes that you have determined that RCU is in fact
	the right tool for your job.		the right tool for your job.

arch/alpha/kernel/process.c

+5 −1

Original line number	Original line	Diff line number	Diff line
	@@ -28,6 +28,7 @@
	#include <linux/tty.h>		#include <linux/tty.h>
	#include <linux/console.h>		#include <linux/console.h>
	#include <linux/slab.h>		#include <linux/slab.h>
			#include <linux/rcupdate.h>

	#include <asm/reg.h>		#include <asm/reg.h>
	#include <asm/uaccess.h>		#include <asm/uaccess.h>
	@@ -54,9 +55,12 @@ cpu_idle(void)
	/* FIXME -- EV6 and LCA45 know how to power down		/* FIXME -- EV6 and LCA45 know how to power down
	the CPU. */		the CPU. */

			rcu_idle_enter();
	while (!need_resched())		while (!need_resched())
	cpu_relax();		cpu_relax();
	schedule();
			rcu_idle_exit();
			schedule_preempt_disabled();
	}		}
	}		}

arch/alpha/kernel/smp.c

+1 −0

Original line number	Original line	Diff line number	Diff line
	@@ -166,6 +166,7 @@ smp_callin(void)
	DBGS(("smp_callin: commencing CPU %d current %p active_mm %p\n",		DBGS(("smp_callin: commencing CPU %d current %p active_mm %p\n",
	cpuid, current, current->active_mm));		cpuid, current, current->active_mm));

			preempt_disable();
	/* Do nothing. */		/* Do nothing. */
	cpu_idle();		cpu_idle();
	}		}