Le 31/10/2017 à 15:58, Boris Brezillon a écrit :
Hi Christophe,
On Sun, 22 Oct 2017 10:28:31 +0200
Christophe JAILLET wrote:
If 'chip->state == FL_SYNCING', we will 'goto retry' with the mutex
'>lock' already taken.
In such a case, the 'mutex_lock' at line 927
Le 31/10/2017 à 15:58, Boris Brezillon a écrit :
Hi Christophe,
On Sun, 22 Oct 2017 10:28:31 +0200
Christophe JAILLET wrote:
If 'chip->state == FL_SYNCING', we will 'goto retry' with the mutex
'>lock' already taken.
In such a case, the 'mutex_lock' at line 927 can never succeed.
In order to
Hi Christophe,
On Sun, 22 Oct 2017 10:28:31 +0200
Christophe JAILLET wrote:
> If 'chip->state == FL_SYNCING', we will 'goto retry' with the mutex
> '>lock' already taken.
> In such a case, the 'mutex_lock' at line 927 can never succeed.
>
> In order to avoid a
Hi Christophe,
On Sun, 22 Oct 2017 10:28:31 +0200
Christophe JAILLET wrote:
> If 'chip->state == FL_SYNCING', we will 'goto retry' with the mutex
> '>lock' already taken.
> In such a case, the 'mutex_lock' at line 927 can never succeed.
>
> In order to avoid a deadlock, move the
If 'chip->state == FL_SYNCING', we will 'goto retry' with the mutex
'>lock' already taken.
In such a case, the 'mutex_lock' at line 927 can never succeed.
In order to avoid a deadlock, move the 'mutex_lock(>lock)' at the
very end of the block.
This has been spotted with the following coccinelle
If 'chip->state == FL_SYNCING', we will 'goto retry' with the mutex
'>lock' already taken.
In such a case, the 'mutex_lock' at line 927 can never succeed.
In order to avoid a deadlock, move the 'mutex_lock(>lock)' at the
very end of the block.
This has been spotted with the following coccinelle
6 matches
Mail list logo