From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 153EC23C
 for <dev@dpdk.org>; Wed,  2 May 2018 13:24:20 +0200 (CEST)
Received: from lfbn-lil-1-169-73.w90-45.abo.wanadoo.fr ([90.45.25.73]
 helo=droids-corp.org)
 by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.89) (envelope-from <olivier.matz@6wind.com>)
 id 1fDps4-0003ZG-2r; Wed, 02 May 2018 13:24:29 +0200
Received: by droids-corp.org (sSMTP sendmail emulation);
 Wed, 02 May 2018 13:24:17 +0200
Date: Wed, 2 May 2018 13:24:17 +0200
From: Olivier Matz <olivier.matz@6wind.com>
To: Jianfeng Tan <jianfeng.tan@intel.com>
Cc: dev@dpdk.org, anatoly.burakov@intel.com, thomas@monjalon.net
Message-ID: <20180502112417.shlwamchx4as4sqw@neon>
References: <1525255198-20906-1-git-send-email-jianfeng.tan@intel.com>
 <1525256270-23138-1-git-send-email-jianfeng.tan@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1525256270-23138-1-git-send-email-jianfeng.tan@intel.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [dpdk-dev] [PATCH v2] eal: fix use-after-free issue on thread
	creation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 11:24:20 -0000

Hi Jianfeng,

On Wed, May 02, 2018 at 10:17:50AM +0000, Jianfeng Tan wrote:
> After below commit, we encounter some strange issue:
>   1) Dead lock as described here:
>      http://dpdk.org/ml/archives/dev/2018-April/099806.html
>   2) SIGSEGV issue when starting a testpmd in VM.
> 
> Considering below commit changes to use dynamic memory instead of
> stack for memory barrier, we doubt it's caused by use-after-free.
> 
> Fixes: 3d09a6e26d8b ("eal: fix threads block on barrier")
> 
> Reported-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> Reported-by: Lei Yao <lei.a.yao@intel.com>
> Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> ---
>  v1->v2:
>  - Destroy barrier if failure happens.
>  lib/librte_eal/common/eal_common_thread.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_thread.c b/lib/librte_eal/common/eal_common_thread.c
> index de69452..5f0c61f 100644
> --- a/lib/librte_eal/common/eal_common_thread.c
> +++ b/lib/librte_eal/common/eal_common_thread.c
> @@ -149,11 +149,16 @@ struct rte_thread_ctrl_params {
>  
>  static void *rte_thread_init(void *arg)
>  {
> +	int ret;
>  	struct rte_thread_ctrl_params *params = arg;
>  	void *(*start_routine)(void *) = params->start_routine;
>  	void *routine_arg = params->arg;
>  
> -	pthread_barrier_wait(&params->configured);
> +	ret = pthread_barrier_wait(&params->configured);
> +	if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
> +		pthread_barrier_destroy(&params->configured);
> +		free(params);
> +	}
>  
>  	return start_routine(routine_arg);
>  }
> @@ -204,12 +209,16 @@ rte_ctrl_thread_create(pthread_t *thread, const char *name,
>  	if (ret < 0)
>  		goto fail;
>  
> -	pthread_barrier_wait(&params->configured);
> -	free(params);
> +	ret = pthread_barrier_wait(&params->configured);
> +	if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
> +		pthread_barrier_destroy(&params->configured);
> +		free(params);
> +	}
>  
>  	return 0;
>  
>  fail:
> +	pthread_barrier_destroy(&params->configured);

I think we should have the same code than above in the fail case:

	ret = pthread_barrier_wait(&params->configured);
	if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
		pthread_barrier_destroy(&params->configured);
		free(params);
	}

Else, the child will wait forever on the barrier on failure.

This can be tested with this standalone program:
https://www.droids-corp.org/~zer0/hidden/ctrl_thread.c

gcc -W -Wall -Werror -Wextra -pthread ctrl_thread.c
./a.out -> fail

gcc -W -Wall -Werror -Wextra -pthread -DFIX ctrl_thread.c
./a.out -> ok



>  	pthread_cancel(*thread);
>  	pthread_join(*thread, NULL);
>  	free(params);
> -- 
> 2.7.4
>