linux-toradex.git, branch v3.2.14-rt23

Merge commit 'v3.2.14' into rt-3.2.14-rt23

2012-04-04T15:52:26+00:00

correct rt patch version to be -rt23

2012-04-04T15:40:09+00:00

Signed-off-by: Clark Williams

kconfig-preempt-rt-full.patch

2012-04-04T14:15:00+00:00

Signed-off-by: Thomas Gleixner

kconfig-disable-a-few-options-rt.patch

2012-04-04T14:15:00+00:00

Disable stuff which is known to have issues on RT

Signed-off-by: Thomas Gleixner

net: Use cpu_chill() instead of cpu_relax()

2012-04-04T14:15:00+00:00

Retry loops on RT might loop forever when the modifying side was
preempted. Use cpu_chill() instead of cpu_relax() to let the system
make progress.

Signed-off-by: Thomas Gleixner 
Cc: stable-rt@vger.kernel.org

fs: dcache: Use cpu_chill() in trylock loops

2012-04-04T14:14:59+00:00

Retry loops on RT might loop forever when the modifying side was
preempted. Use cpu_chill() instead of cpu_relax() to let the system
make progress.

Signed-off-by: Thomas Gleixner 
Cc: stable-rt@vger.kernel.org

rt: Introduce cpu_chill()

2012-04-04T14:14:59+00:00

Retry loops on RT might loop forever when the modifying side was
preempted. Add cpu_chill() to replace cpu_relax(). cpu_chill()
defaults to cpu_relax() for non RT. On RT it puts the looping task to
sleep for a tick so the preempted task can make progress.

Signed-off-by: Thomas Gleixner 
Cc: stable-rt@vger.kernel.org

softirq: Check preemption after reenabling interrupts

2012-04-04T14:14:59+00:00

raise_softirq_irqoff() disables interrupts and wakes the softirq
daemon, but after reenabling interrupts there is no preemption check,
so the execution of the softirq thread might be delayed arbitrarily.

In principle we could add that check to local_irq_enable/restore, but
that's overkill as the rasie_softirq_irqoff() sections are the only
ones which show this behaviour.

Reported-by: Carsten Emde 
Signed-off-by: Thomas Gleixner 
Cc: stable-rt@vger.kernel.org

cpu: Make hotplug.lock a "sleeping" spinlock on RT

2012-04-04T14:14:59+00:00

Tasks can block on hotplug.lock in pin_current_cpu(), but their state
might be != RUNNING. So the mutex wakeup will set the state
unconditionally to RUNNING. That might cause spurious unexpected
wakeups. We could provide a state preserving mutex_lock() function,
but this is semantically backwards. So instead we convert the
hotplug.lock() to a spinlock for RT, which has the state preserving
semantics already.

Signed-off-by: Steven Rostedt 
Cc: Carsten Emde 
Cc: John Kacur 
Cc: Peter Zijlstra 
Cc: Clark Williams 
Cc: stable-rt@vger.kernel.org
Link: http://lkml.kernel.org/r/1330702617.25686.265.camel@gandalf.stny.rr.com
Signed-off-by: Thomas Gleixner

lglock/rt: Use non-rt for_each_cpu() in -rt code

2012-04-04T14:14:59+00:00

Currently the RT version of the lglocks() does a for_each_online_cpu()
in the name##_global_lock_online() functions. Non-rt uses its own
mask for this, and for good reason.

A task may grab a *_global_lock_online(), and in the mean time, one
of the CPUs goes offline. Now when that task does a *_global_unlock_online()
it releases all the locks *except* the one that went offline.

Now if that CPU were to come back on line, its lock is now owned by a
task that never released it when it should have.

This causes all sorts of fun errors. Like owners of a lock no longer
existing, or sleeping on IO, waiting to be woken up by a task that
happens to be blocked on the lock it never released.

Convert the RT versions to use the lglock specific cpumasks. As once
a CPU comes on line, the mask is set, and never cleared even when the
CPU goes offline. The locks for that CPU will still be taken and released.

Signed-off-by: Steven Rostedt 
Cc: Carsten Emde 
Cc: John Kacur 
Cc: Peter Zijlstra 
Cc: Clark Williams 
Cc: stable-rt@vger.kernel.org
Link: http://lkml.kernel.org/r/20120301190345.374756214@goodmis.org
Signed-off-by: Thomas Gleixner