Conflicts:
	include/litmus/affinity.h
	kernel/sched.c
	kernel/softirq.c
	litmus/Kconfig
	litmus/affinity.c
	litmus/litmus.c
	litmus/preempt.c
	litmus/sched_cedf.c
	litmus/sched_gsn_edf.c

Whether to send IPIs and enqueue tasks on remote runqueues is
plugin-specific. The recent ttwu_queue() mechanism (by calling
ttwu_queue_remote()) interferes with Litmus plugin decisions.

Some notes:
* Litmus^RT scheduling class is the topmost scheduling class
  (above stop_sched_class).
* scheduler_ipi() function (e.g., in smp_reschedule_interrupt())
  may increase IPI latencies.
* Added path into schedule() to quickly re-evaluate scheduling
  decision without becoming preemptive again. This used to be
  a standard path before the removal of BKL.

Conflicts:
	Makefile
	arch/arm/kernel/calls.S
	arch/arm/kernel/smp.c
	arch/x86/include/asm/unistd_32.h
	arch/x86/kernel/smp.c
	arch/x86/kernel/syscall_table_32.S
	include/linux/hrtimer.h
	kernel/printk.c
	kernel/sched.c
	kernel/sched_fair.c

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  signal: align __lock_task_sighand() irq disabling and RCU
  softirq,rcu: Inform RCU of irq_exit() activity
  sched: Add irq_{enter,exit}() to scheduler_ipi()
  rcu: protect __rcu_read_unlock() against scheduler-using irq handlers
  rcu: Streamline code produced by __rcu_read_unlock()
  rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special
  rcu: decrease rcu_report_exp_rnp coupling with scheduler

The __lock_task_sighand() function calls rcu_read_lock() with interrupts
and preemption enabled, but later calls rcu_read_unlock() with interrupts
disabled.  It is therefore possible that this RCU read-side critical
section will be preempted and later RCU priority boosted, which means that
rcu_read_unlock() will call rt_mutex_unlock() in order to deboost itself, but
with interrupts disabled. This results in lockdep splats, so this commit
nests the RCU read-side critical section within the interrupt-disabled
region of code.  This prevents the RCU read-side critical section from
being preempted, and thus prevents the attempt to deboost with interrupts
disabled.

It is quite possible that a better long-term fix is to make rt_mutex_unlock()
disable irqs when acquiring the rt_mutex structure's ->wait_lock.

Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>