ipc: unlock on failure

  Reported by Coverity.

Fixes: a2a06860b8c4 ("ipc: fix memory leak on request failure")
Cc: Herakliusz Lipiec <herakliusz.lipiec@intel.com>
Cc: stable@dpdk.org
Cc: Anatoly Burakov <anatoly.burakov@intel.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
---
 lib/librte_eal/common/eal_common_proc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
  

On Mon, May 6, 2019 at 3:11 PM Aaron Conole <aconole@redhat.com> wrote:

> Reported by Coverity.
>
> Fixes: a2a06860b8c4 ("ipc: fix memory leak on request failure")
> Cc: Herakliusz Lipiec <herakliusz.lipiec@intel.com>
> Cc: stable@dpdk.org
> Cc: Anatoly Burakov <anatoly.burakov@intel.com>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
>  lib/librte_eal/common/eal_common_proc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/eal_common_proc.c
> b/lib/librte_eal/common/eal_common_proc.c
> index d23728604..3498e6b07 100644
> --- a/lib/librte_eal/common/eal_common_proc.c
> +++ b/lib/librte_eal/common/eal_common_proc.c
> @@ -1005,8 +1005,10 @@ rte_mp_request_sync(struct rte_mp_msg *req, struct
> rte_mp_reply *reply,
>                 /* unlocks the mutex while waiting for response,
>                  * locks on receive
>                  */
> -               if (mp_request_sync(path, req, reply, &end))
> +               if (mp_request_sync(path, req, reply, &end)) {
> +                       pthread_mutex_unlock(&pending_requests.lock);
>                         goto err;
> +               }
>         }
>         pthread_mutex_unlock(&pending_requests.lock);
>         /* unlock the directory */
> --
> 2.19.1
>

Unfortunately, I think this is more complex than this.
We will leave a flock() pending and leak some resources from opendir().
  

David Marchand <david.marchand@redhat.com> writes:

> On Mon, May 6, 2019 at 3:11 PM Aaron Conole <aconole@redhat.com> wrote:
>
>  Reported by Coverity.
>
>  Fixes: a2a06860b8c4 ("ipc: fix memory leak on request failure")
>  Cc: Herakliusz Lipiec <herakliusz.lipiec@intel.com>
>  Cc: stable@dpdk.org
>  Cc: Anatoly Burakov <anatoly.burakov@intel.com>
>  Signed-off-by: Aaron Conole <aconole@redhat.com>
>  ---
>   lib/librte_eal/common/eal_common_proc.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
>  diff --git a/lib/librte_eal/common/eal_common_proc.c b/lib/librte_eal/common/eal_common_proc.c
>  index d23728604..3498e6b07 100644
>  --- a/lib/librte_eal/common/eal_common_proc.c
>  +++ b/lib/librte_eal/common/eal_common_proc.c
>  @@ -1005,8 +1005,10 @@ rte_mp_request_sync(struct rte_mp_msg *req, struct rte_mp_reply *reply,
>                  /* unlocks the mutex while waiting for response,
>                   * locks on receive
>                   */
>  -               if (mp_request_sync(path, req, reply, &end))
>  +               if (mp_request_sync(path, req, reply, &end)) {
>  +                       pthread_mutex_unlock(&pending_requests.lock);
>                          goto err;
>  +               }
>          }
>          pthread_mutex_unlock(&pending_requests.lock);
>          /* unlock the directory */
>  -- 
>  2.19.1
>
> Unfortunately, I think this is more complex than this.
> We will leave a flock() pending and leak some resources from opendir().

I completely forgot about it, while double checking the mp_request_sync

You're right, we leak the dirfd, still.

Okay, I think see a better way to write this.