summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnurag Singh <anursing@codeaurora.org>2013-03-20 04:14:21 +0400
committerDmitry Shmidt <dimitrysh@google.com>2017-03-04 02:08:34 +0300
commit40bb591cb6abaf540bf9a988e3fac0ca86368865 (patch)
tree88a4435c24280c9d8d01c4cd4129f2e7b761e3d1
parent0bd88c5bb77fc515ab2017c4fbf75594d05c927b (diff)
downloadlinux-sunxi-40bb591cb6abaf540bf9a988e3fac0ca86368865.tar.xz
input: evdev: Move wake_lock_destroy callmirror/android-3.4
Calling wake_lock_destroy from inside a spinlock protected region (or, in general, from atomic context) leads to a 'scheduling while atomic bug' because the internal wakeup source deletion logic calls synchronize_rcu, which can sleep. Moreover, since the interal lists are already protected with RCUs and spinlocks, putting the wake_lock_destroy call in a spinlock is redundant. Change-Id: I10a2239b664a5f43e54495f24fe588fb09282305 Signed-off-by: Anurag Singh <anursing@codeaurora.org>
-rw-r--r--drivers/input/evdev.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 1d6d6c8593fd..6c34600e5ca6 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -710,8 +710,8 @@ static int evdev_disable_suspend_block(struct evdev *evdev,
spin_lock_irq(&client->buffer_lock);
client->use_wake_lock = false;
- wake_lock_destroy(&client->wake_lock);
spin_unlock_irq(&client->buffer_lock);
+ wake_lock_destroy(&client->wake_lock);
return 0;
}