lkml.org 
[lkml]   [2017]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] w1: keep balance of mutex locks and refcnts
From
Date
Hi Evgeniy,

mutex_lock() and atomic_inc() are not nested currently:

ret = mutex_lock_interruptible(&dev->bus_mutex);
...
atomic_inc(THERM_REFCNT(family_data));

...

mutex_unlock(&dev->bus_mutex);
...
atomic_dec(THERM_REFCNT(family_data));

As a result, error handling without returns will be still quite messy.

Is it possible to switch to a nested variant:
mutex_lock-atomic_inc-atomic_dec-mutex_unlock
or
atomic_inc-mutex_lock-mutex_unlock-atomic_dec
?

--
Alexey



On 01.10.2017 08:55, Evgeniy Polyakov wrote:
> Hi Alex
>
> 29.09.2017, 23:23, "Alexey Khoroshilov" <khoroshilov@ispras.ru>:
>> w1_therm_eeprom() and w1_DS18B20_precision() decrement THERM_REFCNT
>> on error paths, while they did not increment it yet.
>>
>> read_therm() unlocks bus mutex on some error paths,
>> while it is not acquired.
>>
>> The patch makes sure all the functions keep the balance in usage of
>> the mutex and the THERM_REFCNT.
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>
> Yes, this looks like a bug, thanks for finding it!
>
> Please update your patch to use single exit point and not a mix of returns in the body of the function.
>
>>          ret = mutex_lock_interruptible(&dev->bus_mutex);
>>          if (ret != 0)
>> - goto post_unlock;
>> + return ret;
>>
>>          if (!sl->family_data) {
>> - ret = -ENODEV;
>> - goto pre_unlock;
>> + mutex_unlock(&dev->bus_mutex);
>> + return -ENODEV;
>>          }
>

\
 
 \ /
  Last update: 2017-10-07 19:59    [W:0.084 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site