Project

General

Profile

Actions

Feature #1940

open

032: Locking a mutex twice or unlocking without prior locking

Added by Alexey Khoroshilov over 10 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Start date:
10/25/2011
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

You should not acquire or release the same mutex twice in the same process. All locked mutexes should be unlocked at finalization.

Description

There are several things you should watch for:
  1. Double-locking. Mutex-type object provides exclusive access to sections of executable code. Thus retrying to acquire the current mutex will inevitably lead to a deadlock-situation. Deadlocks should be avoided, hence no double locks should take place.
  2. Releasing an unlocked mutex.
  3. Leaving a mutex locked at finalization.

Mutex is a special case of semaphore, restricted with just one possible requestor. However, it has its own wrapping functions. To initialize a mutex, macros are often used: DECLARE_MUTEX(name) and DECLARE_MUTEX_LOCKED(name). Locking is provided via mutex_lock(), mutex_trylock() and mutex_lock_interruptible() functions; unlocking--via mutex_unlock().

Links
Sample bugfixes 4a349aa, a9e7fb5, d47b389, c1c7415, 8a9f335, 723342c


Related issues 2 (0 open2 closed)

Related to Linux Driver Verification - Bug #1412: 32_7: add atomic_dec_and_mutex_lock to the modelClosedPavel Shved06/23/2011

Actions
Has duplicate Linux Kernel Safety RuleDB - Feature #3324: 32: Locking a mutex twice or unlocking without prior lockingClosedEvgeny Novikov08/03/2012

Actions
Actions

Also available in: Atom PDF