[Mesa-dev] Fwd: New Defects reported by Coverity Scan for Mesa

[Emil Velikov]

On 13 April 2016 at 22:03, Dongwon Kim <dongwon.kim at intel.com> wrote:
> There are four different places where the program pointer may jump to
> 'cleanup:' while the mutex is still possilby being locked. Two
> of those cases are when mtx_lock(pthread_mutex_lock) fails to lock
> the mutex. However, this can't be a problem because the mutex is either
> not in "locked" state because current thread fails to acquire it or
> even if it's locked, it's owned by another thread.
>
> The other two places are when mtx_unlock call fails to unlock the mutex.
> This is also not a problem. According to manpage, pthread_mutex_unlock
> only can return EINVAL or EPERM. EINVAL means the mutex is not
> initialized. But if it's uninialized, the code should have already
> failed while trying to acquiring it. EPERM is also not an issue
> because this error code means current thread doesn't own the mutex.
> In other words, the function is not responsible for unlocking it.
>
All of these will disappear if we drop checking the return value of
mtx_{un,}lock, right ?

Iirc it was one of the suggestions mentioned alongside the "the
function does not return TRUE/FALSE" one ;-)

-Emil