Incorrect use of mutex operations can cause deadlocks, failure of exclusion, and so on. To detect and prevent such possible occurrences, the mutex subsystem is equipped with appropriate checks or validations instrumented into mutex operations. These checks are by default disabled, and can be enabled by choosing the configuration option CONFIG_DEBUG_MUTEXES=y during kernel build.

Following is a list of checks enforced by instrumented debug code:

• Mutex can be owned by one task at a given point in time
• Mutex can be released (unlocked) only by the valid owner, and an attempt to release mutex by a context that does not own the lock will fail
• Recursive locking or unlocking attempts will fail
• A mutex can only be initialized via the initializer call, and any attempt to memset mutex will never succeed
• A caller task may not exit with a mutex lock held
• Dynamic memory areas where held locks reside must not be freed
• A mutex can be initialized once, and any attempt to re-initialize an already initialized mutex will fail
• Mutexes may not be used in hard/soft interrupt context routines

Deadlocks can trigger due to many reasons, such as the execution pattern of the kernel code and careless usage of locking calls. For instance, let's consider a situation where concurrent code paths need to take ownership of L₁ and L₂ locks by nesting the locking functions. It must be ensured that all the kernel functions that require these locks are programmed to acquire them in the same order. When such ordering is not strictly imposed, there is always a possibility of two different functions trying to lock L1 and L2 in opposite order, which could trigger lock inversion deadlock, when these functions execute concurrently.

The kernel lock validator infrastructure has been implemented to check and prove that none of the locking patterns observed during kernel runtime could ever cause deadlock. This infrastructure prints data pertaining to locking pattern such as:

• Point-of-acquire tracking, symbolic lookup of function names, and list of all locks held in the system
• Owner tracking
• Detection of self-recursing locks and printing out all relevant info
• Detection of lock inversion deadlocks and printing out all affected locks and tasks

The lock validator can be enabled by choosing CONFIG_PROVE_LOCKING=y during kernel build.