title: Linux kernel: Unlocking an unlocked mutex
body: <p>I am trying to understand the "unlocking an unlocked mutex" is not allowed will lead to unpredictable behavior w.r.t Linux kernel mutex, when i look at the code i do not see anything to this effect.</p>
  
  <p>Specifically:</p>
  
  <pre><code>/**
   * try to promote the mutex from 0 to 1. if it wasn't 0, call &lt;function&gt;
   * In the failure case, this function is allowed to either set the value to
   * 1, or to set it to a value lower than one.
   * If the implementation sets it to a value of lower than one, the
   * __mutex_slowpath_needs_to_unlock() macro needs to return 1, it needs
   * to return 0 otherwise.
   */
  static inline void
  __mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
  {
      if (unlikely(atomic_xchg(count, 1) != 0))
          fail_fn(count);
  }
  </code></pre>
  
  <p>where fail_fn is</p>
  
  <pre><code>static inline void
  __mutex_unlock_common_slowpath(atomic_t *lock_count, int nested)
  {
      struct mutex *lock = container_of(lock_count, struct mutex, count);
      unsigned long flags;
  
      spin_lock_mutex(&amp;lock-&gt;wait_lock, flags);
      mutex_release(&amp;lock-&gt;dep_map, nested, _RET_IP_);
      debug_mutex_unlock(lock);
  
      /*
       * some architectures leave the lock unlocked in the fastpath failure
       * case, others need to leave it locked. In the later case we have to
       * unlock it here
       */
      if (__mutex_slowpath_needs_to_unlock())
          atomic_set(&amp;lock-&gt;count, 1);
  
      if (!list_empty(&amp;lock-&gt;wait_list)) {
          /* get the first entry from the wait-list: */
          struct mutex_waiter *waiter =
                  list_entry(lock-&gt;wait_list.next,
                         struct mutex_waiter, list);
  
          debug_mutex_wake_waiter(lock, waiter);
  
          wake_up_process(waiter-&gt;task);
      }
  
      spin_unlock_mutex(&amp;lock-&gt;wait_lock, flags);
  }
  </code></pre>
  
  <p>From what i can tell if it is unlocked it will remain unlocked regardless of what __mutex_slowpath_needs_to_unlock() is, am i missing something here?</p>