Re: [PATCH] mtd: lpddr: Fix a potential double mutex_lock

2017-11-03 Thread Christophe JAILLET
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

Re: [PATCH] mtd: lpddr: Fix a potential double mutex_lock

2017-11-03 Thread Christophe JAILLET
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

Re: [PATCH] mtd: lpddr: Fix a potential double mutex_lock

2017-10-31 Thread Boris Brezillon
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

Re: [PATCH] mtd: lpddr: Fix a potential double mutex_lock

2017-10-31 Thread Boris Brezillon
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

[PATCH] mtd: lpddr: Fix a potential double mutex_lock

2017-10-22 Thread Christophe JAILLET
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

[PATCH] mtd: lpddr: Fix a potential double mutex_lock

2017-10-22 Thread Christophe JAILLET
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