[PATCH] lock/semaphore: Avoid a deadlock within __up()

[Byungchul Park]

When the semaphore __up() is called from within printk() with
console_sem.lock, a DEADLOCK can happen, since the wake_up_process() can
call printk() again, esp. if defined CONFIG_DEBUG_SPINLOCK. And the
wake_up_process() don't need to be within a critical section.

The scenario the bad thing can happen is,

printk
  console_trylock
  console_unlock
    up_console_sem
      up
        raw_spin_lock_irqsave(&sem->lock, flags)
        __up
          wake_up_process
            try_to_wake_up
              raw_spin_lock_irqsave(&p->pi_lock)
                __spin_lock_debug
                  spin_dump
                    printk
                      console_trylock
                        raw_spin_lock_irqsave(&sem->lock, flags)

                        *** DEADLOCK ***

Signed-off-by: Byungchul Park <byungchul.park@xxxxxxx>
---
 kernel/locking/semaphore.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index b8120ab..d3a28dc 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -259,5 +259,14 @@ static noinline void __sched __up(struct semaphore *sem)
 						struct semaphore_waiter, list);
 	list_del(&waiter->list);
 	waiter->up = true;
+
+	/*
+	 * Trying to acquire this sem->lock in wake_up_process() leads a
+	 * DEADLOCK unless we unlock it here. For example, it's possile
+	 * in the case that called from within printk() since
+	 * wake_up_process() might call printk().
+	 */
+	raw_spin_unlock_irq(&sem->lock);
 	wake_up_process(waiter->task);
+	raw_spin_lock_irq(&sem->lock);
 }
-- 
1.9.1