Project

General

Profile

Actions

Feature #3324

closed

32: Locking a mutex twice or unlocking without prior locking

Added by Ilya Shchepetkov almost 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Start date:
08/03/2012
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

(copied from kernel-rules/rules/DRVRULES_en.trl)

Summary

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.

Example

void edac_device_reset_delay_period(struct edac_device_ctl_info *edac_dev, unsigned long value)  
{  
    mutex_lock(&device_ctls_mutex); /*acquire the device_ctls_mutex*/  

    /* cancel the current workq request */  
    edac_device_workq_teardown(edac_dev); /* function acquires the lock device_ctls_mutex */  
    /* leads to a double lock */  

    /* restart the workq request, with new delay value */  
    edac_device_workq_setup(edac_dev, value);  
    ... 

Related issues 2 (2 open0 closed)

Related to Linux Driver Verification - Bug #785: Develop model 32_8 that takes into account mutex_lock_nested, etc.New02/03/2011

Actions
Is duplicate of Linux Kernel Safety RuleDB - Feature #1940: 032: Locking a mutex twice or unlocking without prior lockingNew10/25/2011

Actions
Actions

Also available in: Atom PDF