Commit Graph

377134 Commits

Author SHA1 Message Date
Paul E. McKenney
971394f389 rcu: Fix deadlock with CPU hotplug, RCU GP init, and timer migration
In Steven Rostedt's words:

> I've been debugging the last couple of days why my tests have been
> locking up. One of my tracing tests, runs all available tracers. The
> lockup always happened with the mmiotrace, which is used to trace
> interactions between priority drivers and the kernel. But to do this
> easily, when the tracer gets registered, it disables all but the boot
> CPUs. The lockup always happened after it got done disabling the CPUs.
>
> Then I decided to try this:
>
> while :; do
> 	for i in 1 2 3; do
> 		echo 0 > /sys/devices/system/cpu/cpu$i/online
> 	done
> 	for i in 1 2 3; do
> 		echo 1 > /sys/devices/system/cpu/cpu$i/online
> 	done
> done
>
> Well, sure enough, that locked up too, with the same users. Doing a
> sysrq-w (showing all blocked tasks):
>
> [ 2991.344562]   task                        PC stack   pid father
> [ 2991.344562] rcu_preempt     D ffff88007986fdf8     0    10      2 0x00000000
> [ 2991.344562]  ffff88007986fc98 0000000000000002 ffff88007986fc48 0000000000000908
> [ 2991.344562]  ffff88007986c280 ffff88007986ffd8 ffff88007986ffd8 00000000001d3c80
> [ 2991.344562]  ffff880079248a40 ffff88007986c280 0000000000000000 00000000fffd4295
> [ 2991.344562] Call Trace:
> [ 2991.344562]  [<ffffffff815437ba>] schedule+0x64/0x66
> [ 2991.344562]  [<ffffffff81541750>] schedule_timeout+0xbc/0xf9
> [ 2991.344562]  [<ffffffff8154bec0>] ? ftrace_call+0x5/0x2f
> [ 2991.344562]  [<ffffffff81049513>] ? cascade+0xa8/0xa8
> [ 2991.344562]  [<ffffffff815417ab>] schedule_timeout_uninterruptible+0x1e/0x20
> [ 2991.344562]  [<ffffffff810c980c>] rcu_gp_kthread+0x502/0x94b
> [ 2991.344562]  [<ffffffff81062791>] ? __init_waitqueue_head+0x50/0x50
> [ 2991.344562]  [<ffffffff810c930a>] ? rcu_gp_fqs+0x64/0x64
> [ 2991.344562]  [<ffffffff81061cdb>] kthread+0xb1/0xb9
> [ 2991.344562]  [<ffffffff81091e31>] ? lock_release_holdtime.part.23+0x4e/0x55
> [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
> [ 2991.344562]  [<ffffffff8154c1dc>] ret_from_fork+0x7c/0xb0
> [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
> [ 2991.344562] kworker/0:1     D ffffffff81a30680     0    47      2 0x00000000
> [ 2991.344562] Workqueue: events cpuset_hotplug_workfn
> [ 2991.344562]  ffff880078dbbb58 0000000000000002 0000000000000006 00000000000000d8
> [ 2991.344562]  ffff880078db8100 ffff880078dbbfd8 ffff880078dbbfd8 00000000001d3c80
> [ 2991.344562]  ffff8800779ca5c0 ffff880078db8100 ffffffff81541fcf 0000000000000000
> [ 2991.344562] Call Trace:
> [ 2991.344562]  [<ffffffff81541fcf>] ? __mutex_lock_common+0x3d4/0x609
> [ 2991.344562]  [<ffffffff815437ba>] schedule+0x64/0x66
> [ 2991.344562]  [<ffffffff81543a39>] schedule_preempt_disabled+0x18/0x24
> [ 2991.344562]  [<ffffffff81541fcf>] __mutex_lock_common+0x3d4/0x609
> [ 2991.344562]  [<ffffffff8103d11b>] ? get_online_cpus+0x3c/0x50
> [ 2991.344562]  [<ffffffff8103d11b>] ? get_online_cpus+0x3c/0x50
> [ 2991.344562]  [<ffffffff815422ff>] mutex_lock_nested+0x3b/0x40
> [ 2991.344562]  [<ffffffff8103d11b>] get_online_cpus+0x3c/0x50
> [ 2991.344562]  [<ffffffff810af7e6>] rebuild_sched_domains_locked+0x6e/0x3a8
> [ 2991.344562]  [<ffffffff810b0ec6>] rebuild_sched_domains+0x1c/0x2a
> [ 2991.344562]  [<ffffffff810b109b>] cpuset_hotplug_workfn+0x1c7/0x1d3
> [ 2991.344562]  [<ffffffff810b0ed9>] ? cpuset_hotplug_workfn+0x5/0x1d3
> [ 2991.344562]  [<ffffffff81058e07>] process_one_work+0x2d4/0x4d1
> [ 2991.344562]  [<ffffffff81058d3a>] ? process_one_work+0x207/0x4d1
> [ 2991.344562]  [<ffffffff8105964c>] worker_thread+0x2e7/0x3b5
> [ 2991.344562]  [<ffffffff81059365>] ? rescuer_thread+0x332/0x332
> [ 2991.344562]  [<ffffffff81061cdb>] kthread+0xb1/0xb9
> [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
> [ 2991.344562]  [<ffffffff8154c1dc>] ret_from_fork+0x7c/0xb0
> [ 2991.344562]  [<ffffffff81061c2a>] ? __init_kthread_worker+0x58/0x58
> [ 2991.344562] bash            D ffffffff81a4aa80     0  2618   2612 0x10000000
> [ 2991.344562]  ffff8800379abb58 0000000000000002 0000000000000006 0000000000000c2c
> [ 2991.344562]  ffff880077fea140 ffff8800379abfd8 ffff8800379abfd8 00000000001d3c80
> [ 2991.344562]  ffff8800779ca5c0 ffff880077fea140 ffffffff81541fcf 0000000000000000
> [ 2991.344562] Call Trace:
> [ 2991.344562]  [<ffffffff81541fcf>] ? __mutex_lock_common+0x3d4/0x609
> [ 2991.344562]  [<ffffffff815437ba>] schedule+0x64/0x66
> [ 2991.344562]  [<ffffffff81543a39>] schedule_preempt_disabled+0x18/0x24
> [ 2991.344562]  [<ffffffff81541fcf>] __mutex_lock_common+0x3d4/0x609
> [ 2991.344562]  [<ffffffff81530078>] ? rcu_cpu_notify+0x2f5/0x86e
> [ 2991.344562]  [<ffffffff81530078>] ? rcu_cpu_notify+0x2f5/0x86e
> [ 2991.344562]  [<ffffffff815422ff>] mutex_lock_nested+0x3b/0x40
> [ 2991.344562]  [<ffffffff81530078>] rcu_cpu_notify+0x2f5/0x86e
> [ 2991.344562]  [<ffffffff81091c99>] ? __lock_is_held+0x32/0x53
> [ 2991.344562]  [<ffffffff81548912>] notifier_call_chain+0x6b/0x98
> [ 2991.344562]  [<ffffffff810671fd>] __raw_notifier_call_chain+0xe/0x10
> [ 2991.344562]  [<ffffffff8103cf64>] __cpu_notify+0x20/0x32
> [ 2991.344562]  [<ffffffff8103cf8d>] cpu_notify_nofail+0x17/0x36
> [ 2991.344562]  [<ffffffff815225de>] _cpu_down+0x154/0x259
> [ 2991.344562]  [<ffffffff81522710>] cpu_down+0x2d/0x3a
> [ 2991.344562]  [<ffffffff81526351>] store_online+0x4e/0xe7
> [ 2991.344562]  [<ffffffff8134d764>] dev_attr_store+0x20/0x22
> [ 2991.344562]  [<ffffffff811b3c5f>] sysfs_write_file+0x108/0x144
> [ 2991.344562]  [<ffffffff8114c5ef>] vfs_write+0xfd/0x158
> [ 2991.344562]  [<ffffffff8114c928>] SyS_write+0x5c/0x83
> [ 2991.344562]  [<ffffffff8154c494>] tracesys+0xdd/0xe2
>
> As well as held locks:
>
> [ 3034.728033] Showing all locks held in the system:
> [ 3034.728033] 1 lock held by rcu_preempt/10:
> [ 3034.728033]  #0:  (rcu_preempt_state.onoff_mutex){+.+...}, at: [<ffffffff810c9471>] rcu_gp_kthread+0x167/0x94b
> [ 3034.728033] 4 locks held by kworker/0:1/47:
> [ 3034.728033]  #0:  (events){.+.+.+}, at: [<ffffffff81058d3a>] process_one_work+0x207/0x4d1
> [ 3034.728033]  #1:  (cpuset_hotplug_work){+.+.+.}, at: [<ffffffff81058d3a>] process_one_work+0x207/0x4d1
> [ 3034.728033]  #2:  (cpuset_mutex){+.+.+.}, at: [<ffffffff810b0ec1>] rebuild_sched_domains+0x17/0x2a
> [ 3034.728033]  #3:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8103d11b>] get_online_cpus+0x3c/0x50
> [ 3034.728033] 1 lock held by mingetty/2563:
> [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
> [ 3034.728033] 1 lock held by mingetty/2565:
> [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
> [ 3034.728033] 1 lock held by mingetty/2569:
> [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
> [ 3034.728033] 1 lock held by mingetty/2572:
> [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
> [ 3034.728033] 1 lock held by mingetty/2575:
> [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
> [ 3034.728033] 7 locks held by bash/2618:
> [ 3034.728033]  #0:  (sb_writers#5){.+.+.+}, at: [<ffffffff8114bc3f>] file_start_write+0x2a/0x2c
> [ 3034.728033]  #1:  (&buffer->mutex#2){+.+.+.}, at: [<ffffffff811b3b93>] sysfs_write_file+0x3c/0x144
> [ 3034.728033]  #2:  (s_active#54){.+.+.+}, at: [<ffffffff811b3c3e>] sysfs_write_file+0xe7/0x144
> [ 3034.728033]  #3:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff810217c2>] cpu_hotplug_driver_lock+0x17/0x19
> [ 3034.728033]  #4:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8103d196>] cpu_maps_update_begin+0x17/0x19
> [ 3034.728033]  #5:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8103cfd8>] cpu_hotplug_begin+0x2c/0x6d
> [ 3034.728033]  #6:  (rcu_preempt_state.onoff_mutex){+.+...}, at: [<ffffffff81530078>] rcu_cpu_notify+0x2f5/0x86e
> [ 3034.728033] 1 lock held by bash/2980:
> [ 3034.728033]  #0:  (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff8131e28a>] n_tty_read+0x252/0x7e8
>
> Things looked a little weird. Also, this is a deadlock that lockdep did
> not catch. But what we have here does not look like a circular lock
> issue:
>
> Bash is blocked in rcu_cpu_notify():
>
> 1961		/* Exclude any attempts to start a new grace period. */
> 1962		mutex_lock(&rsp->onoff_mutex);
>
>
> kworker is blocked in get_online_cpus(), which makes sense as we are
> currently taking down a CPU.
>
> But rcu_preempt is not blocked on anything. It is simply sleeping in
> rcu_gp_kthread (really rcu_gp_init) here:
>
> 1453	#ifdef CONFIG_PROVE_RCU_DELAY
> 1454			if ((prandom_u32() % (rcu_num_nodes * 8)) == 0 &&
> 1455			    system_state == SYSTEM_RUNNING)
> 1456				schedule_timeout_uninterruptible(2);
> 1457	#endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
>
> And it does this while holding the onoff_mutex that bash is waiting for.
>
> Doing a function trace, it showed me where it happened:
>
> [  125.940066] rcu_pree-10      3.... 28384115273: schedule_timeout_uninterruptible <-rcu_gp_kthread
> [...]
> [  125.940066] rcu_pree-10      3d..3 28384202439: sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=D ==> next_comm=watchdog/3 next_pid=38 next_prio=120
>
> The watchdog ran, and then:
>
> [  125.940066] watchdog-38      3d..3 28384692863: sched_switch: prev_comm=watchdog/3 prev_pid=38 prev_prio=120 prev_state=P ==> next_comm=modprobe next_pid=2848 next_prio=118
>
> Not sure what modprobe was doing, but shortly after that:
>
> [  125.940066] modprobe-2848    3d..3 28385041749: sched_switch: prev_comm=modprobe prev_pid=2848 prev_prio=118 prev_state=R+ ==> next_comm=migration/3 next_pid=40 next_prio=0
>
> Where the migration thread took down the CPU:
>
> [  125.940066] migratio-40      3d..3 28389148276: sched_switch: prev_comm=migration/3 prev_pid=40 prev_prio=0 prev_state=P ==> next_comm=swapper/3 next_pid=0 next_prio=120
>
> which finally did:
>
> [  125.940066]   <idle>-0       3...1 28389282142: arch_cpu_idle_dead <-cpu_startup_entry
> [  125.940066]   <idle>-0       3...1 28389282548: native_play_dead <-arch_cpu_idle_dead
> [  125.940066]   <idle>-0       3...1 28389282924: play_dead_common <-native_play_dead
> [  125.940066]   <idle>-0       3...1 28389283468: idle_task_exit <-play_dead_common
> [  125.940066]   <idle>-0       3...1 28389284644: amd_e400_remove_cpu <-play_dead_common
>
>
> CPU 3 is now offline, the rcu_preempt thread that ran on CPU 3 is still
> doing a schedule_timeout_uninterruptible() and it registered it's
> timeout to the timer base for CPU 3. You would think that it would get
> migrated right? The issue here is that the timer migration happens at
> the CPU notifier for CPU_DEAD. The problem is that the rcu notifier for
> CPU_DOWN is blocked waiting for the onoff_mutex to be released, which is
> held by the thread that just put itself into a uninterruptible sleep,
> that wont wake up until the CPU_DEAD notifier of the timer
> infrastructure is called, which wont happen until the rcu notifier
> finishes. Here's our deadlock!

This commit breaks this deadlock cycle by substituting a shorter udelay()
for the previous schedule_timeout_uninterruptible(), while at the same
time increasing the probability of the delay.  This maintains the intensity
of the testing.

Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
2013-06-10 13:37:12 -07:00
Steven Rostedt
016a8d5be6 rcu: Don't call wakeup() with rcu_node structure ->lock held
This commit fixes a lockdep-detected deadlock by moving a wake_up()
call out from a rnp->lock critical section.  Please see below for
the long version of this story.

On Tue, 2013-05-28 at 16:13 -0400, Dave Jones wrote:

> [12572.705832] ======================================================
> [12572.750317] [ INFO: possible circular locking dependency detected ]
> [12572.796978] 3.10.0-rc3+ #39 Not tainted
> [12572.833381] -------------------------------------------------------
> [12572.862233] trinity-child17/31341 is trying to acquire lock:
> [12572.870390]  (rcu_node_0){..-.-.}, at: [<ffffffff811054ff>] rcu_read_unlock_special+0x9f/0x4c0
> [12572.878859]
> but task is already holding lock:
> [12572.894894]  (&ctx->lock){-.-...}, at: [<ffffffff811390ed>] perf_lock_task_context+0x7d/0x2d0
> [12572.903381]
> which lock already depends on the new lock.
>
> [12572.927541]
> the existing dependency chain (in reverse order) is:
> [12572.943736]
> -> #4 (&ctx->lock){-.-...}:
> [12572.960032]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
> [12572.968337]        [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
> [12572.976633]        [<ffffffff8113c987>] __perf_event_task_sched_out+0x2e7/0x5e0
> [12572.984969]        [<ffffffff81088953>] perf_event_task_sched_out+0x93/0xa0
> [12572.993326]        [<ffffffff816ea0bf>] __schedule+0x2cf/0x9c0
> [12573.001652]        [<ffffffff816eacfe>] schedule_user+0x2e/0x70
> [12573.009998]        [<ffffffff816ecd64>] retint_careful+0x12/0x2e
> [12573.018321]
> -> #3 (&rq->lock){-.-.-.}:
> [12573.034628]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
> [12573.042930]        [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
> [12573.051248]        [<ffffffff8108e6a7>] wake_up_new_task+0xb7/0x260
> [12573.059579]        [<ffffffff810492f5>] do_fork+0x105/0x470
> [12573.067880]        [<ffffffff81049686>] kernel_thread+0x26/0x30
> [12573.076202]        [<ffffffff816cee63>] rest_init+0x23/0x140
> [12573.084508]        [<ffffffff81ed8e1f>] start_kernel+0x3f1/0x3fe
> [12573.092852]        [<ffffffff81ed856f>] x86_64_start_reservations+0x2a/0x2c
> [12573.101233]        [<ffffffff81ed863d>] x86_64_start_kernel+0xcc/0xcf
> [12573.109528]
> -> #2 (&p->pi_lock){-.-.-.}:
> [12573.125675]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
> [12573.133829]        [<ffffffff816ebe9b>] _raw_spin_lock_irqsave+0x4b/0x90
> [12573.141964]        [<ffffffff8108e881>] try_to_wake_up+0x31/0x320
> [12573.150065]        [<ffffffff8108ebe2>] default_wake_function+0x12/0x20
> [12573.158151]        [<ffffffff8107bbf8>] autoremove_wake_function+0x18/0x40
> [12573.166195]        [<ffffffff81085398>] __wake_up_common+0x58/0x90
> [12573.174215]        [<ffffffff81086909>] __wake_up+0x39/0x50
> [12573.182146]        [<ffffffff810fc3da>] rcu_start_gp_advanced.isra.11+0x4a/0x50
> [12573.190119]        [<ffffffff810fdb09>] rcu_start_future_gp+0x1c9/0x1f0
> [12573.198023]        [<ffffffff810fe2c4>] rcu_nocb_kthread+0x114/0x930
> [12573.205860]        [<ffffffff8107a91d>] kthread+0xed/0x100
> [12573.213656]        [<ffffffff816f4b1c>] ret_from_fork+0x7c/0xb0
> [12573.221379]
> -> #1 (&rsp->gp_wq){..-.-.}:
> [12573.236329]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
> [12573.243783]        [<ffffffff816ebe9b>] _raw_spin_lock_irqsave+0x4b/0x90
> [12573.251178]        [<ffffffff810868f3>] __wake_up+0x23/0x50
> [12573.258505]        [<ffffffff810fc3da>] rcu_start_gp_advanced.isra.11+0x4a/0x50
> [12573.265891]        [<ffffffff810fdb09>] rcu_start_future_gp+0x1c9/0x1f0
> [12573.273248]        [<ffffffff810fe2c4>] rcu_nocb_kthread+0x114/0x930
> [12573.280564]        [<ffffffff8107a91d>] kthread+0xed/0x100
> [12573.287807]        [<ffffffff816f4b1c>] ret_from_fork+0x7c/0xb0

Notice the above call chain.

rcu_start_future_gp() is called with the rnp->lock held. Then it calls
rcu_start_gp_advance, which does a wakeup.

You can't do wakeups while holding the rnp->lock, as that would mean
that you could not do a rcu_read_unlock() while holding the rq lock, or
any lock that was taken while holding the rq lock. This is because...
(See below).

> [12573.295067]
> -> #0 (rcu_node_0){..-.-.}:
> [12573.309293]        [<ffffffff810b8d36>] __lock_acquire+0x1786/0x1af0
> [12573.316568]        [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
> [12573.323825]        [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
> [12573.331081]        [<ffffffff811054ff>] rcu_read_unlock_special+0x9f/0x4c0
> [12573.338377]        [<ffffffff810760a6>] __rcu_read_unlock+0x96/0xa0
> [12573.345648]        [<ffffffff811391b3>] perf_lock_task_context+0x143/0x2d0
> [12573.352942]        [<ffffffff8113938e>] find_get_context+0x4e/0x1f0
> [12573.360211]        [<ffffffff811403f4>] SYSC_perf_event_open+0x514/0xbd0
> [12573.367514]        [<ffffffff81140e49>] SyS_perf_event_open+0x9/0x10
> [12573.374816]        [<ffffffff816f4dd4>] tracesys+0xdd/0xe2

Notice the above trace.

perf took its own ctx->lock, which can be taken while holding the rq
lock. While holding this lock, it did a rcu_read_unlock(). The
perf_lock_task_context() basically looks like:

rcu_read_lock();
raw_spin_lock(ctx->lock);
rcu_read_unlock();

Now, what looks to have happened, is that we scheduled after taking that
first rcu_read_lock() but before taking the spin lock. When we scheduled
back in and took the ctx->lock, the following rcu_read_unlock()
triggered the "special" code.

The rcu_read_unlock_special() takes the rnp->lock, which gives us a
possible deadlock scenario.

	CPU0		CPU1		CPU2
	----		----		----

				     rcu_nocb_kthread()
    lock(rq->lock);
		    lock(ctx->lock);
				     lock(rnp->lock);

				     wake_up();

				     lock(rq->lock);

		    rcu_read_unlock();

		    rcu_read_unlock_special();

		    lock(rnp->lock);
    lock(ctx->lock);

**** DEADLOCK ****

> [12573.382068]
> other info that might help us debug this:
>
> [12573.403229] Chain exists of:
>   rcu_node_0 --> &rq->lock --> &ctx->lock
>
> [12573.424471]  Possible unsafe locking scenario:
>
> [12573.438499]        CPU0                    CPU1
> [12573.445599]        ----                    ----
> [12573.452691]   lock(&ctx->lock);
> [12573.459799]                                lock(&rq->lock);
> [12573.467010]                                lock(&ctx->lock);
> [12573.474192]   lock(rcu_node_0);
> [12573.481262]
>  *** DEADLOCK ***
>
> [12573.501931] 1 lock held by trinity-child17/31341:
> [12573.508990]  #0:  (&ctx->lock){-.-...}, at: [<ffffffff811390ed>] perf_lock_task_context+0x7d/0x2d0
> [12573.516475]
> stack backtrace:
> [12573.530395] CPU: 1 PID: 31341 Comm: trinity-child17 Not tainted 3.10.0-rc3+ #39
> [12573.545357]  ffffffff825b4f90 ffff880219f1dbc0 ffffffff816e375b ffff880219f1dc00
> [12573.552868]  ffffffff816dfa5d ffff880219f1dc50 ffff88023ce4d1f8 ffff88023ce4ca40
> [12573.560353]  0000000000000001 0000000000000001 ffff88023ce4d1f8 ffff880219f1dcc0
> [12573.567856] Call Trace:
> [12573.575011]  [<ffffffff816e375b>] dump_stack+0x19/0x1b
> [12573.582284]  [<ffffffff816dfa5d>] print_circular_bug+0x200/0x20f
> [12573.589637]  [<ffffffff810b8d36>] __lock_acquire+0x1786/0x1af0
> [12573.596982]  [<ffffffff810918f5>] ? sched_clock_cpu+0xb5/0x100
> [12573.604344]  [<ffffffff810b9851>] lock_acquire+0x91/0x1f0
> [12573.611652]  [<ffffffff811054ff>] ? rcu_read_unlock_special+0x9f/0x4c0
> [12573.619030]  [<ffffffff816ebc90>] _raw_spin_lock+0x40/0x80
> [12573.626331]  [<ffffffff811054ff>] ? rcu_read_unlock_special+0x9f/0x4c0
> [12573.633671]  [<ffffffff811054ff>] rcu_read_unlock_special+0x9f/0x4c0
> [12573.640992]  [<ffffffff811390ed>] ? perf_lock_task_context+0x7d/0x2d0
> [12573.648330]  [<ffffffff810b429e>] ? put_lock_stats.isra.29+0xe/0x40
> [12573.655662]  [<ffffffff813095a0>] ? delay_tsc+0x90/0xe0
> [12573.662964]  [<ffffffff810760a6>] __rcu_read_unlock+0x96/0xa0
> [12573.670276]  [<ffffffff811391b3>] perf_lock_task_context+0x143/0x2d0
> [12573.677622]  [<ffffffff81139070>] ? __perf_event_enable+0x370/0x370
> [12573.684981]  [<ffffffff8113938e>] find_get_context+0x4e/0x1f0
> [12573.692358]  [<ffffffff811403f4>] SYSC_perf_event_open+0x514/0xbd0
> [12573.699753]  [<ffffffff8108cd9d>] ? get_parent_ip+0xd/0x50
> [12573.707135]  [<ffffffff810b71fd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [12573.714599]  [<ffffffff81140e49>] SyS_perf_event_open+0x9/0x10
> [12573.721996]  [<ffffffff816f4dd4>] tracesys+0xdd/0xe2

This commit delays the wakeup via irq_work(), which is what
perf and ftrace use to perform wakeups in critical sections.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2013-06-10 13:37:11 -07:00
Paul E. McKenney
d62840995a trace: Allow idle-safe tracepoints to be called from irq
__DECLARE_TRACE_RCU() currently creates an _rcuidle() tracepoint which
may safely be invoked from what RCU considers to be an idle CPU.
However, these _rcuidle() tracepoints may -not- be invoked from the
handler of an irq taken from idle, because rcu_idle_enter() zeroes
RCU's nesting-level counter, so that the rcu_irq_exit() returning to
idle will trigger a WARN_ON_ONCE().

This commit therefore substitutes rcu_irq_enter() for rcu_idle_exit()
and rcu_irq_exit() for rcu_idle_enter() in order to make the _rcuidle()
tracepoints usable from irq handlers as well as from process context.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
2013-06-10 13:37:10 -07:00
David S. Miller
d88210910a Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
Pablo Neira Ayuso says:

====================
The following patchset contains four fixes for Netfilter and one fix
for IPVS, they are:

* Fix data leak to user-space via getsockopt IP_VS_SO_GET_DESTS, from
  Dan Carpenter.

* Fix xt_TCPMSS if no TCP MSS is specified in syn packets, to avoid the
  violation of RFC879, from Phil Oester.

* Fix incomplete dump of objects via nfnetlink_acct and nfnetlink_cttimeout,
  from myself.

* Fix missing HW protocol in packets passed to user-space via NFQUEUE,
  from myself.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-10 13:30:33 -07:00
Linus Torvalds
ab0296319a spi: Fixes for v3.10
A few nasty issues, particularly a race with the interrupt controller in
 the xilinx driver, together with a couple of more minor fixes and a much
 needed move of the mailing list away from sourceforge.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJRrissAAoJELSic+t+oim99qsQAJZJsEnlp/NOSt7OmPVrXv4c
 4nlqSFgqNA0wEwIjgRJgusVQsSPlTzmJpoMJrA1PDSV5lC6ilaqo1z2Nlg6w0PzL
 BGJU72vbmfCd9+rIqm5icEZPDG5CajM5fFl6cngNDUhPbOYz1Lo+DHVebkBp9won
 SNEG2UM2GL5orEvPNvy6DRrLJLBnfFAtezyC8gcL9Q4wyL2woQAaF3FaytFvL0sz
 lehIwejLQgJ9Irzz+ciqQQI+jWyII2pjSWBXb9tmoL1HAeeODrxeH/Qs1dn/s9MQ
 3ImWAOhQJCjajBzwRxuvW+I08piAr8ZaMMbVhLBUR2ZuJcjEdcJ2h5zKdU97cv2D
 hFS1JJjb1f88iOJMmcApE/NM8FVtJJjit5G6NaNGcEIi2RriTNZ6ZP8bfxvC1/sT
 wBXG3C8KTMYKHhYkM0LmBI5deQGgj5Xm1Yq/aFLiil0UCrnxIK/1cWY5UT6EWWpa
 /G6UfkE4Vt13leW/xPJtpPM9q2dsSzGFIf108t7DAVIsg2kCKFQ58yLqi4uNNnxl
 yqyhW2dCfFmas9+Oef4XdQa4e7SWQ6hCmXx1x4GncY9y/PeJqRmbpq4ROW6HwCgy
 URNvbJGoJxv+hzNlpTVI18MEq4ej1dTwJCHnMjtZir6Nt0nbjofxpCplsbRkwN4b
 eI0ubMqyFUBpTcXgYPuu
 =Lvj8
 -----END PGP SIGNATURE-----

Merge tag 'spi-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

Pull spi fixes from Mark Brown:
 "A few nasty issues, particularly a race with the interrupt controller
  in the xilinx driver, together with a couple of more minor fixes and a
  much needed move of the mailing list away from sourceforge."

* tag 'spi-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: hspi: fixup long delay time
  spi: spi-xilinx: Remove ISR race condition
  spi: topcliff-pch: fix error return code in pch_spi_probe()
  spi: topcliff-pch: Pass correct pointer to free_irq()
  spi: Move mailing list to vger
2013-06-10 13:28:39 -07:00
Linus Torvalds
50e6f8511a Bug-fixes for regressions:
- xen/tmem stopped working after a certain combination of modprobe/swapon was used
  - cpu online/offlining would trigger WARN_ON.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.13 (GNU/Linux)
 
 iQEcBAABAgAGBQJRtgQxAAoJEFjIrFwIi8fJ9QYH/ibEGBlKLfGzN4Apx6evBA68
 l9CuLIpGCkPOiJLgVs10zY77Sg3f95bHFkJrwrEIDeTQ42joNKybsIp+qZCIS5CW
 sAnzSd6Mb8jqQYJpgLl03+z3GdFzILTJ9e0zYTETbW2vfLpAETm87XWH+gjxDK0e
 9I0kZX+Q3+2VWi5xv+UwWkYIOLbggLyKYajTHDwWNuC7vQgkJulCAbmjgN/NBv7A
 xacvXdbEClIfZ5tvJJN0RggdEWo6WyTxyExfLPmpXFbHEvWDUX5LPEf8MhFY1ORK
 U1C0BSV6YuLo350G5lY4I0R75ZEWLeUyVkZFnJIeGnUF1rP6OXEuVWTyeivPDBA=
 =Fy36
 -----END PGP SIGNATURE-----

Merge tag 'stable/for-linus-3.10-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull xen fixes from Konrad Rzeszutek Wilk:
 "Two bug-fixes for regressions:
   - xen/tmem stopped working after a certain combination of
     modprobe/swapon was used
   - cpu online/offlining would trigger WARN_ON."

* tag 'stable/for-linus-3.10-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it.
  xen/smp: Fixup NOHZ per cpu data when onlining an offline CPU.
2013-06-10 13:27:46 -07:00
Linus Torvalds
30f5f73926 regmap: Fixes for v3.10
The biggest fix here is Lars-Peter's fix for custom locking callbacks
 which is pretty localised but important for those devices that use the
 feature.  Otherwise we've got a couple of fairly small cleanups which
 would have been sent sooner were it not for letting Lars-Peter's patch
 soak for a while.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJRtZ9aAAoJELSic+t+oim9FKsP/09KdtRUMGIjJQFX3Lm4bEoU
 0ZQhvV6ozQWa+3faKlUeBu61yUx4R+zAgxO3rJHSEZM2+50bTZ9t70InvHOegKU7
 ipayoR/4cS23kK0uZJL9TURmoK4JuII+QVlTX/Fn9siJrrFvoSSOHjv7DxGzPZtt
 o4xgK+R8WU6zTUVIf2ncHzryaKPMs50tEt7FjPTMn+MetWsn0kgYxk3VLsORQqnL
 VJwzusJn/Z+vIy4kr9NAFGV6UljecRrIzFmn98kVHgMW1nEjr3vEE1upP2Y1TrF3
 flZqooulg7qlc2bL60/aakWXAWQ33lKZCvtMHykk46cUFN0faSbL3V9wk1N/85AN
 n6wHZKHA9APGMeImv1nL+p3DLZkhY3HYpuOgoSP8ocUpZ7y7C0wH+oGBO3nmLGjK
 4vEGPClsNFrdeF5viViIQ7ECHd9ls7t182gj3UJJjKPi27N5KppXM2ki3TQZABsS
 Q+iZ1dk/GYdyUV2E6LhoBGNnB9v6zo5pi/bABT59KuM0G6SuieRpPbchxo0VIvqY
 6cUZrzJ8Kn9VRDIc5/RIgijm9VjhbGGas/gc5nr014IKiSHMjPVXvBQ3NYw7yQw/
 SFtLgu2UBb+twQ7TWGK7BG6clHtwvSEjnvCFzPJ1q77c1gXzNfY8mCOYjfyEZ5Tb
 JuxD5znZHTvNLo+1QRQh
 =mOJz
 -----END PGP SIGNATURE-----

Merge tag 'regmap-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

Pull regmap fixes from Mark Brown:
 "The biggest fix here is Lars-Peter's fix for custom locking callbacks
  which is pretty localised but important for those devices that use the
  feature.  Otherwise we've got a couple of fairly small cleanups which
  would have been sent sooner were it not for letting Lars-Peter's patch
  soak for a while"

* tag 'regmap-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: rbtree: Fixed node range check on sync
  regmap: regcache: Fixup locking for custom lock callbacks
  regmap: debugfs: Check return value of regmap_write()
2013-06-10 13:26:41 -07:00
Linus Torvalds
822b4b6fe3 Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
 "This fixes a build problem in sahara and temporarily disables two new
  optimisations because of performance regressions until a permanent fix
  is ready"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: sahara - fix building as module
  crypto: blowfish - disable AVX2 implementation
  crypto: twofish - disable AVX2 implementation
2013-06-10 13:25:50 -07:00
Markos Chandras
cb2f9938d0 MIPS: ftrace: Add missing CONFIG_DYNAMIC_FTRACE
arch_ftrace_update_code and ftrace_modify_all_code are only
available if CONFIG_DYNAMIC_FTRACE is selected.

Fixes the following build problem on MIPS randconfig:

arch/mips/kernel/ftrace.c: In function 'arch_ftrace_update_code':
arch/mips/kernel/ftrace.c:31:2: error: implicit declaration of function
'ftrace_modify_all_code' [-Werror=implicit-function-declaration]

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5435/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-06-10 18:15:18 +02:00
Markos Chandras
d414976d1c MIPS: include: mmu_context.h: Replace VIRTUALIZATION with KVM
The kvm_* symbols are only available if KVM is selected.

Fixes the following linking problem on a randconfig:

arch/mips/built-in.o: In function `local_flush_tlb_mm':
(.text+0x18a94): undefined reference to `kvm_local_flush_tlb_all'
arch/mips/built-in.o: In function `local_flush_tlb_range':
(.text+0x18d0c): undefined reference to `kvm_local_flush_tlb_all'
kernel/built-in.o: In function `__schedule':
core.c:(.sched.text+0x2a00): undefined reference to `kvm_local_flush_tlb_all'
mm/built-in.o: In function `use_mm':
(.text+0x30214): undefined reference to `kvm_local_flush_tlb_all'
fs/built-in.o: In function `flush_old_exec':
(.text+0xf0a0): undefined reference to `kvm_local_flush_tlb_all'
make: *** [vmlinux] Error 1

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5437/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-06-10 18:07:43 +02:00
Manuel Lauss
e63a24ddc7 MIPS: Alchemy: fix wait function
Only an interrupt can wake the core from 'wait', enable interrupts
locally before executing 'wait'.

[ralf@linux-mips.org: This leave the race between an interrupt that's
setting TIF_NEED_RESCHEd and entering the WAIT status. but at least it's
going to bring Alchemy back from the dead, so I'm going to apply this
patch.]

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/5408/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-06-10 17:59:46 +02:00
Konrad Rzeszutek Wilk
b2c75c446a xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it.
Commit 10a7a07713 ("xen: tmem: enable Xen
tmem shim to be built/loaded as a module") allows the tmem module
to be loaded any time. For this work the frontswap API had to
be able to asynchronously to call tmem_frontswap_init before
or after the swap image had been set. That was added in git
commit 905cd0e1bf
("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").

Which means we could do this (The common case):

 modprobe tmem		[so calls frontswap_register_ops, no ->init]
			 modifies tmem_frontswap_poolid = -1
 swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
			 < 0 so tmem hypercall done]

Or the failing one:

 swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
 modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
			tmem_frontswap_poolid is 0, does not make a hypercall.
			Later in the module_init, sets tmem_frontswap_poolid=-1]

Which meant that in the failing case we would not call the hypercall
to initialize the pool and never be able to make any frontswap
backend calls.

Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
fixes it.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Bob Liu <bob.liu@oracle.com>
2013-06-10 10:14:33 -04:00
Ben Hutchings
c46b54f740 s390/pci: Implement IRQ functions if !PCI
All architectures must implement IRQ functions.  Since various
dependencies on !S390 were removed, there are various drivers that can
be selected but will fail to link.  Provide a dummy implementation of
these functions for the !PCI case.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org # 3.9
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-06-10 16:06:04 +02:00
Dan Carpenter
a8241c6351 ipvs: info leak in __ip_vs_get_dest_entries()
The entry struct has a 2 byte hole after ->port and another 4 byte
hole after ->stats.outpkts.  You must have CAP_NET_ADMIN in your
namespace to hit this information leak.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-06-10 14:53:00 +02:00
Rafael J. Wysocki
8c9b7a7b2f ACPI / video: Do not bind to device objects with a scan handler
With the introduction of ACPI scan handlers, ACPI device objects
with an ACPI scan handler attached to them must not be bound to
by ACPI drivers any more.  Unfortunately, however, the ACPI video
driver attempts to do just that if there is a _ROM ACPI control
method defined under a device object with an ACPI scan handler.

Prevent that from happening by making the video driver's "add"
routine check if the device object already has an ACPI scan handler
attached to it and return an error code in that case.

That is not sufficient, though, because acpi_bus_driver_init() would
then clear the device object's driver_data that may be set by its
scan handler, so for the fix to work acpi_bus_driver_init() has to be
modified to leave driver_data as is on errors.

References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Bisected-and-tested-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
Reported-and-tested-by: Jason Cassell <bluesloth600@gmail.com>
Tracked-down-by: Aaron Lu <aaron.lu@intel.com>
Cc: 3.9+ <stable@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-06-10 13:00:29 +02:00
Mark Brown
902a75cdc4 Merge remote-tracking branch 'asoc/fix/wm8994' into asoc-linus 2013-06-10 10:28:51 +01:00
Mark Brown
4351ac5b9f Merge remote-tracking branch 'asoc/fix/tlv320aic3x' into asoc-linus 2013-06-10 10:28:50 +01:00
Mark Brown
97a47ce9d2 Merge remote-tracking branch 'asoc/fix/maintainers' into asoc-linus 2013-06-10 10:28:50 +01:00
Mark Brown
ed75019204 Merge remote-tracking branch 'asoc/fix/cs42l52' into asoc-linus 2013-06-10 10:28:49 +01:00
Mark Brown
56f1275b85 Merge remote-tracking branch 'asoc/fix/core' into asoc-linus 2013-06-10 10:28:49 +01:00
Mark Brown
97e0002aab Merge remote-tracking branch 'asoc/fix/arizona' into asoc-linus 2013-06-10 10:28:48 +01:00
Daniel Vetter
c3456fb3e4 drm/i915: prefer VBT modes for SVDO-LVDS over EDID
In

commit 53d3b4d777
Author: Egbert Eich <eich@suse.de>
Date:   Tue Jun 4 17:13:21 2013 +0200

    drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC

Egbert Eich fixed a long-standing bug where we simply used a
non-working i2c controller to read the EDID for SDVO-LVDS panels.
Unfortunately some machines seem to not be able to cope with the mode
provided in the EDID. Specifically they seem to not be able to cope
with a 4x pixel mutliplier instead of a 2x one, which seems to have
been worked around by slightly changing the panels native mode in the
VBT so that the dotclock is just barely above 50MHz.

Since it took forever to notice the breakage it's fairly safe to
assume that at least for SDVO-LVDS panels the VBT contains fairly sane
data. So just switch around the order and use VBT modes first.

v2: Also add EDID modes just in case, and spell Egbert correctly.

v3: Elaborate a bit more about what's going on on Chris' machine.

Cc: Egbert Eich <eich@suse.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
Cc: stable@vger.kernel.org
Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10 10:13:34 +02:00
Chris Wilson
7ba220cec0 drm/i915: Enable hotplug interrupts after querying hw capabilities.
sdvo->hotplug_active is initialised during intel_sdvo_setup_outputs(),
and so we never enabled the hotplug interrupts on SDVO as we were
checking too early.

This regression has been introduced somewhere in the hpd rework for
the storm detection and handling starting with

commit 1d843f9de4
Author: Egbert Eich <eich@suse.de>
Date:   Mon Feb 25 12:06:49 2013 -0500

    DRM/I915: Add enum hpd_pin to intel_encoder.

and the follow-up patches to use the new encoder->hpd_pin variable for
the different irq setup functions.

The problem is that encoder->hpd_pin was set up _before_ the output
setup was done and so before we could assess the hotplug capabilities
of the outputs on an sdvo encoder.

Reported-by: Alex Fiestas <afiestas@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10 09:59:26 +02:00
Chris Wilson
7ee2aff373 drm/i915: Fix hotplug interrupt enabling for SDVOC
A broken conditional would lead to SDVOC waiting upon hotplug events on
SDVOB - and so miss all activity on its SDVO port.

This regression has been introduced in

commit 1d843f9de4
Author: Egbert Eich <eich@suse.de>
Date:   Mon Feb 25 12:06:49 2013 -0500

    DRM/I915: Add enum hpd_pin to intel_encoder.

References: https://bugs.freedesktop.org/show_bug.cgi?id=58405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-06-10 09:58:18 +02:00
Linus Torvalds
ae75d84f3e Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
Pull powerpc fixes from Benjamin Herrenschmidt:
 "This is purely regressions (though not all recent ones) or stable
  material"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Partial revert of "Context switch more PMU related SPRs"
  powerpc/perf: Fix deadlock caused by calling printk() in PMU exception
  powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression
  powerpc/power8: Update denormalization handler
  powerpc/pseries: Simplify denormalization handler
  powerpc/power8: Fix oprofile and perf
  powerpc/eeh: Don't check RTAS token to get PE addr
  powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources
2013-06-09 18:01:45 -07:00
Linus Torvalds
0b52a3c89c Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm
Pull ARM fixes from Russell King:
 "The biggest two fixes are fixing a compilation error with the
  decompressor, and a problem with our __my_cpu_offset implementation.

  Other changes are very trivial and small, which seems to be the way
  for most -rc stuff."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier()
  ARM: 7750/1: update legacy CPU ID in decompressor cache support jump table
  ARM: 7743/1: compressed/head.S: work around new binutils warning
  ARM: 7742/1: topology: export cpu_topology
  ARM: 7737/1: fix kernel decompressor compilation error with CONFIG_DEBUG_SEMIHOSTING
2013-06-09 17:15:56 -07:00
Michael Ellerman
b11ae95100 powerpc: Partial revert of "Context switch more PMU related SPRs"
In commit 59affcd I added context switching of more PMU SPRs, because
they are potentially exposed to userspace on Power8. However despite me
being a smart arse in the commit message it's actually not correct. In
particular it interacts badly with a global perf record.

We will have to do something more complicated, but that will have to
wait for 3.11.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:35 +10:00
Michael Ellerman
6772faa1ba powerpc/perf: Fix deadlock caused by calling printk() in PMU exception
In commit bc09c21 "Fix finding overflowed PMC in interrupt" we added
a printk() to the PMU exception handler. Unfortunately that is not safe.

The problem is that the PMU exception may run even when interrupts are
soft disabled, aka NMI context. We do this so that we can profile parts
of the kernel that have interrupts soft-disabled.

But by calling printk() from the exception handler, we can potentially
deadlock in the printk code on logbuf_lock, eg:

  [c00000038ba575c0] c000000000081928 .vprintk_emit+0xa8/0x540
  [c00000038ba576a0] c0000000007bcde8 .printk+0x48/0x58
  [c00000038ba57710] c000000000076504 .perf_event_interrupt+0x2d4/0x490
  [c00000038ba57810] c00000000001f6f8 .performance_monitor_exception+0x48/0x60
  [c00000038ba57880] c0000000000032cc performance_monitor_common+0x14c/0x180
  --- Exception: f01 (Performance Monitor) at c0000000007b25d4 ._raw_spin_lock_irq
  +0x64/0xc0
  [c00000038ba57bf0] c00000000007ed90 .devkmsg_read+0xd0/0x5a0
  [c00000038ba57d00] c0000000001c2934 .vfs_read+0xc4/0x1e0
  [c00000038ba57d90] c0000000001c2cd8 .SyS_read+0x58/0xd0
  [c00000038ba57e30] c000000000009d54 syscall_exit+0x0/0x98
  --- Exception: c01 (System Call) at 00001fffffbf6f7c
  SP (3ffff6d4de10) is in userspace

Fix it by making sure we only call printk() when we are not in NMI
context.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Cc: <stable@vger.kernel.org> # 3.9
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:32 +10:00
Michael Neuling
82a9f16adc powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression
When introducing support for DABRX in 4474ef0, we broke older 32-bit CPUs
that don't have that register.

Some CPUs have a DABR but not DABRX.  Configuration are:
- No 32bit CPUs have DABRX but some have DABR.
- POWER4+ and below have the DABR but no DABRX.
- 970 and POWER5 and above have DABR and DABRX.
- POWER8 has DAWR, hence no DABRX.

This introduces CPU_FTR_DABRX and sets it on appropriate CPUs.  We use
the top 64 bits for CPU FTR bits since only 64 bit CPUs have this.

Processors that don't have the DABRX will still work as they will fall
back to software filtering these breakpoints via perf_exclude_event().

Signed-off-by: Michael Neuling <mikey@neuling.org>
Reported-by: "Gorelik, Jacob (335F)" <jacob.gorelik@jpl.nasa.gov>
cc: stable@vger.kernel.org (v3.9 only)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:29 +10:00
Michael Neuling
fb0fce3e55 powerpc/power8: Update denormalization handler
POWER8 can take a denormalisation exception on any VSX registers.

This does the extra 32 VSX registers we don't currently handle.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:26 +10:00
Michael Neuling
d7c67fb1cf powerpc/pseries: Simplify denormalization handler
The following simplifies the denorm code by using macros to generate the long
stream of almost identical instructions.

This patch results in no changes to the output binary, but removes a lot of
lines of code.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:22 +10:00
Michael Neuling
6a60f9e7d8 powerpc/power8: Fix oprofile and perf
In 2ac6f42 powerpc/cputable: Fix oprofile_cpu_type on power8
we broke all power8 hw events.

This reverts this change and uses oprofile_type instead. Perf now works
on POWER8 again and oprofile will revert to using timers on POWER8.

Kudos to mpe this fix.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:19 +10:00
Gavin Shan
b8b3de224f powerpc/eeh: Don't check RTAS token to get PE addr
RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2"
are used to retrieve the PE address according to PCI address, which
made up of domain/bus/slot/function. If we don't have those 2 tokens,
the domain/bus/slot/function would be used as the address for EEH
RTAS operations. Some older f/w might not have those 2 tokens and
that blocks the EEH functionality to be initialized. It was introduced
by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization").

The patch skips the check on those 2 tokens so we can bring up EEH
functionality successfully. And domain/bus/slot/function will be
used as address for EEH RTAS operations.

Cc: <stable@vger.kernel.org> # v3.4+
Reported-by: Robert Knight <knight@princeton.edu>
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Tested-by: Robert Knight <knight@princeton.edu>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:16 +10:00
Kevin Hao
c5df457ffe powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources
If a BAR has the value of 0, we would assume that it is unset yet and
then mark the resource as unset and would reassign it later. But after
commit 6c5705fe (powerpc/PCI: get rid of device resource fixups)
the pcibios_fixup_resources is invoked after the bus address was
translated to linux resource. So the value of res->start is resource
address. And since the resource and bus address may be different, we
should translate it to the bus address before doing the check.

Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-10 08:36:13 +10:00
Linus Torvalds
6dbda5bfe1 Improve chip detection in ADM1021 driver to avoid misdetections
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJRsz1aAAoJEMsfJm/On5mBpq8QAKydDEjh16CnScNzjqED6vgv
 lLXBlD7/WeJcyqd6yktVM5tigkSblyZiyn9ydJ9s+3IcI4NBVBYse3n2Bu37Daet
 AfeCHnwVfyKJdIs+wpWyZs7nI2xJn4SHmulV2fKL2HC3GosyRA/A7b5Oodxs+3Jj
 5qtYeAMxCaUYbmJu9otx6FmJQgrQErjPBKJvawhQs9aMfzohzSVSfQOXCiPS8HGX
 Pyu7oUEvbbpS40dsGe4LuP1oA8oMXJM8OOl2MiJnAUQB7+J/uE+H2ztkoWE2vyMt
 n2rX+sjEz+G+JbFUAfvXBNqHLoVvceQcZ1GCBD1y33VJxhLzqVsm+O6fGqlq16pK
 FNV8r4tn+KrO+P0EuCSCKm2TwhP1+cWf4GM7VygUktMKtIYB5/CAtyy/XkRDexcD
 NLe0rjzQ/XRuvZyOnnPVt6QqNfGJVnVSrSM06KSsiHBHsKry20ne2ycEFWnGASFT
 5LBz+r6en4D3qBV0mldrMy4rEUDi0eFnqC7YRvrQEYxQl+x9vzr9Tkd7Kn+vdKri
 /qNtqY8FsaHFhaUVsB/tPHRooAM0Xoweqp307YjKtiycemx6mlQnuXOKplCmHLTn
 VXTvmsMA2EQMSgF2ZPW8yn5eZeaja5RcBpjM9crdCIRAgAjYw+B6IFC44g9GaOlJ
 kV26YR8WyOfsPdK24Dxs
 =lVk4
 -----END PGP SIGNATURE-----

Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

Pull hwmon fix from Guenter Roeck:
 "Improve chip detection in ADM1021 driver to avoid misdetections

  This is not a critical patch, but one we'll want to have applied to
  -stable, since the misdetection especially of LM84 has been causing
  trouble for quite some time."

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617
2013-06-09 14:56:48 -07:00
Patrik Jakobsson
70b1304eee drm/gma500/cdv: Fix cursor gem obj referencing on cdv
The internal crtc cursor gem object pointer was never set/updated since
it was required to be set in the first place.

Fixing this will make the pin/unpin count match and prevent cursor
objects from leaking when userspace drops all references to it. Also
make sure we drop the gem obj reference on failure.

This patch only affects Cedarview chips.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-06-09 18:03:57 +02:00
Patrik Jakobsson
3463cf1aad drm/gma500/psb: Fix cursor gem obj referencing on psb
The internal crtc cursor gem object pointer was never set/updated since
it was required to be set in the first place.

Fixing this will make the pin/unpin count match and prevent cursor
objects from leaking when userspace drops all references to it. Also
make sure we drop the gem obj reference on failure.

This patch only affects Poulsbo chips.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-06-09 18:03:32 +02:00
Patrik Jakobsson
22e7c385a8 drm/gma500/cdv: Unpin framebuffer on crtc disable
The framebuffer needs to be unpinned in the crtc->disable callback
because of previous pinning in psb_intel_pipe_set_base(). This will fix
a memory leak where the framebuffer was released but not unpinned
properly. This patch only affects Cedarview.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-06-09 18:03:20 +02:00
Patrik Jakobsson
820de86a90 drm/gma500/psb: Unpin framebuffer on crtc disable
The framebuffer needs to be unpinned in the crtc->disable callback
because of previous pinning in psb_intel_pipe_set_base(). This will fix
a memory leak where the framebuffer was released but not unpinned
properly. This patch only affects Poulsbo.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
2013-06-09 18:02:02 +02:00
Linus Torvalds
317ddd256b Linux 3.10-rc5 2013-06-08 17:41:04 -07:00
Mikulas Patocka
bbd465df73 hpfs: fix warnings when the filesystem fills up
This patch fixes warnings due to missing lock on write error path.

  WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]()
  Hardware name: empty
  Pid: 26563, comm: dd Tainted: P           O 3.9.4 #12
  Call Trace:
    hpfs_truncate+0x75/0x80 [hpfs]
    hpfs_write_begin+0x84/0x90 [hpfs]
    _hpfs_bmap+0x10/0x10 [hpfs]
    generic_file_buffered_write+0x121/0x2c0
    __generic_file_aio_write+0x1c7/0x3f0
    generic_file_aio_write+0x7c/0x100
    do_sync_write+0x98/0xd0
    hpfs_file_write+0xd/0x50 [hpfs]
    vfs_write+0xa2/0x160
    sys_write+0x51/0xa0
    page_fault+0x22/0x30
    system_call_fastpath+0x1a/0x1f

Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: stable@kernel.org  # 2.6.39+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-06-08 17:39:40 -07:00
Linus Torvalds
81db4dbf59 Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Thomas Gleixner:

 - Trivial: unused variable removal

 - Posix-timers: Add the clock ID to the new proc interface to make it
   useful.  The interface is new and should be functional when we reach
   the final 3.10 release.

 - Cure a false positive warning in the tick code introduced by the
   overhaul in 3.10

 - Fix for a persistent clock detection regression introduced in this
   cycle

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  timekeeping: Correct run-time detection of persistent_clock.
  ntp: Remove unused variable flags in __hardpps
  posix-timers: Show clock ID in proc file
  tick: Cure broadcast false positive pending bit warning
2013-06-08 15:51:21 -07:00
Linus Torvalds
c3e58a7945 irqdomain bug fixes for v3.10-rc4
This branch contains a set of straight forward bug fixes to the
 irqdomain code and to a couple of drivers that make use of it.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJRs51nAAoJEEFnBt12D9kBmnUP/RCgaTn5biRD0tC6OCGwvsZr
 YKypc71cZtbO3CTk1Sw2jgDUoW+2FWwtbwKWCmrHIaulRuxoeMHLbpc6fEGFRAjG
 ENnSEuSJkYV2T5ZoYjM5mAjotHUcszxZ9uOz7ovCUY72GO/+tfJ97NT9+CCpPfWV
 Wa/i08/91UPbWP1ASfMLXVzqO9uqEYvrrvY2PSqJ/g0BkzbybAg38u6IycZkGW4u
 /mjglx5fYRhcQgl7o1FDaw97AGjbykt2mgP7EK3R24BxvEy4gmn4IzGo9duOf7Y2
 b1tEfro/keRoibuKehPWdKTvpda80DUJjrsOwmNveZHTWlSB8GZXqCEmOmTHngrV
 gNX6MUVZClUvKiQCDo3ibyZUmIuUnnlRee6WqQzr2VsMiwct449Gg81zwXX+Yn7O
 5KOnlyicJur3f4HqQSKEA2CXU6RRCmk2iqCFMqtutxy20cmm3LoW7OM7rFF7tzix
 g6czKZiX+yKwoP2E2EQ2mYM8cirKeEyPhs4EUnKJJOVVZqOCtHkrKnkbSoithsS3
 we6Isj8KM8NQ3fgeFsbcxV+ezK3moIzD0fYr3Q6x25VZLYrYH7XpUix0nlGYxCOK
 vlEpCaMes/IG/+SKElf8fPoxs0qlOYPvYZBrLjUGCG/VB01bNsj0mjKYm1va+f6v
 n3zQbGS7X+TiiHQ+EFL0
 =wZCk
 -----END PGP SIGNATURE-----

Merge tag 'irqdomain-for-linus' of git://git.secretlab.ca/git/linux

Pull irqdomain bug fixes from Grant Likely:
 "This branch contains a set of straight forward bug fixes to the
  irqdomain code and to a couple of drivers that make use of it."

* tag 'irqdomain-for-linus' of git://git.secretlab.ca/git/linux:
  irqchip: Return -EPERM for reserved IRQs
  irqdomain: document the simple domain first_irq
  kernel/irq/irqdomain.c: before use 'irq_data', need check it whether valid.
  irqdomain: export irq_domain_add_simple
2013-06-08 15:50:42 -07:00
Grant Likely
d94ea3f6d2 irqchip: Return -EPERM for reserved IRQs
The irqdomain core will report a log message for any attempted map call
that fails unless the error code is -EPERM. This patch changes the
Versatile irq controller drivers to use -EPERM because it is normal for
a subset of the IRQ inputs to be marked as reserved on the various
Versatile platforms.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
2013-06-08 21:34:16 +01:00
Linus Walleij
94a63da0ac irqdomain: document the simple domain first_irq
The first_irq needs to be zero to get a linear domain and that
comes with special semantics. We want to simplify this going
forward but some documentation never hurts.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
2013-06-08 21:15:09 +01:00
Chen Gang
275e31b10c kernel/irq/irqdomain.c: before use 'irq_data', need check it whether valid.
Since irq_data may be NULL, if so, we WARN_ON(), and continue, 'hwirq'
which related with 'irq_data' has to initialize later, or it will cause
issue.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
2013-06-08 21:15:09 +01:00
Arnd Bergmann
346dbb79ea irqdomain: export irq_domain_add_simple
All other irq_domain_add_* functions are exported already, and apparently
this one got left out by mistake, which causes build errors for ARM
allmodconfig kernels:

ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-rcar.ko] undefined!
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
2013-06-08 21:15:08 +01:00
Linus Torvalds
50b4b9c3e8 ARM: SoC fixes for 3.10-rc
Another week, another batch of fixes for arm-soc platforms.
 
 Nothing controversial here, a handful of fixes for regressions and/or
 serious problems across several of the platforms. Things are slowing
 down nicely on fix rates for 3.10.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJRs2w/AAoJEIwa5zzehBx39KsP/2loDpDbxWD4z1YYPXqpXkUt
 /r49WbMBuwxgK8adc1hXUTYQSDECQ9boqKbH/Jyt5edn7lR5JctYeGO7z9tlmQhs
 HrbFK9QVcidK5J6+0DJwwZPQcS03f4KQ/p529tVihmYVoQx8vQKe9buevn9pD5cg
 ud8vlbJ3tPZGC5DJCpJpZd/+GkAlnCRTrUt//rzV2ZkK/PbvTp8lpWqz8f87Audu
 fnpUVJXFmK4Q5PsSwXCK7WfACW6uokFDH52ofj/L3MFMYZXzZFVpUTnTORkx5uOt
 8xokh1YFuYGhG5rSDNEwysUqHuy8eBSyrts8woV+5J3TlNZh/oHcDCW+c0FoP5EB
 5PdTMrLBSDcelQkiaKINWKT5kcQ3FncKrXSTbbPg2PQFvexUal142bLsQAsU6ZPl
 cQBDaCPQu+J8qzGkeHZAhKl+82AwfNKffNgTPDdoe236rHOH9XWv+TPA4cGxLD6n
 vAqon661oQ4byRowMlb9liTWZP0wVrd/ZkakyGiwiCsiZm6qR0tc5tZwzvib4dko
 BDsp2F8dIKxqFSA524SZdcx0P0J3yPcP9EP/XTpYpnmSbBFdYIUZcySMQcNLFOh+
 spkbTnTToL1Kb9HgikXE8BQGx17pqg7RGekpBdWVrnAKeBri5Lyorelxmh0+dlI0
 Bsr89mVwh8AJq/Pi6Vib
 =BUV/
 -----END PGP SIGNATURE-----

Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "Another week, another batch of fixes for arm-soc platforms.

  Nothing controversial here, a handful of fixes for regressions and/or
  serious problems across several of the platforms.  Things are slowing
  down nicely on fix rates for 3.10"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: exynos: add debug_ll_io_init() call in exynos_init_io()
  ARM: EXYNOS: uncompress - print debug messages if DEBUG_LL is defined
  ARM: shmobile: sh73a0: Update CMT clockevent rating to 80
  sh-pfc: r8a7779: Don't group USB OVC and PENC pins
  ARM: mxs: icoll: Fix interrupts gpio bank 0
  ARM: imx: clk-imx6q: AXI clock select index is incorrect
  ARM: bcm2835: override the HW UART periphid
  ARM: mvebu: Fix bug in coherency fabric low level init function
  ARM: Kirkwood: TS219: Fix crash by double PCIe instantiation
  ARM: ux500: Provide supplies for AUX1, AUX2 and AUX3
  ARM: ux500: Only configure wake-up reasons on ux500 based platforms
  ARM: dts: imx: fix clocks for cspi
  ARM i.MX6q: fix for ldb_di_sels
2013-06-08 11:56:22 -07:00
Linus Torvalds
554e6e9f81 Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
Pull MIPS fixes from Ralf Baechle:
 "MIPS fixes across the field.  The only area that's standing out is the
  exception handling which received it's dose of breakage as part of the
  microMIPS patchset"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: ralink: add missing SZ_1M multiplier
  MIPS: Compat: Fix cputime_to_timeval() arguments in compat binfmt_elf.
  MIPS: OCTEON: Improve _machine_halt implementation.
  MIPS: rtlx: Fix implicit declaration of function set_vi_handler()
  MIPS: Trap exception handling fixes
  MIPS: Quit exposing Kconfig symbols in uapi headers.
  MIPS: Remove duplicate definition of check_for_high_segbits.
2013-06-08 11:51:13 -07:00
Linus Torvalds
17d8dfcda6 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
Pull m68knommu fix from Greg Ungerer:
 "A single fix for compilation breakage to many of the ColdFire CPU
  targets"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68k: only use local gpio_request_one if not using GPIOLIB
2013-06-08 11:50:17 -07:00