From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E58F4A0566; Tue, 10 Mar 2020 20:14:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 14CDC1C02C; Tue, 10 Mar 2020 20:14:37 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 681F81C02B for ; Tue, 10 Mar 2020 20:14:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583867674; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=92zNQZYBZoXMN3pxN//ap9V8sSuHhD9ogXqTnLvK9vg=; b=bcAnrRb71YNXk4/bWwq4dcq4Soa4EZj/00tIsnnFvrF/mDyfI1P2VMC01WjkfRXi7nNtcs jYD1LKo/fqAWW4GEmZghCtQVJLJgeynvvlcSNOXsHwxAOYJirvoA2FQx7lQFPvHnr1GJGr WweA99vvZRj37GRmv5gCyKGFsw9hsJw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-59-omf4--mGPAmQKzlSIIVOiQ-1; Tue, 10 Mar 2020 15:14:32 -0400 X-MC-Unique: omf4--mGPAmQKzlSIIVOiQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B5E1B1005514; Tue, 10 Mar 2020 19:14:31 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 924118D56A; Tue, 10 Mar 2020 19:14:28 +0000 (UTC) From: Aaron Conole To: "Van Haaren\, Harry" Cc: David Marchand , dev References: <20200310133304.39951-1-harry.van.haaren@intel.com> Date: Tue, 10 Mar 2020 15:14:27 -0400 In-Reply-To: (Aaron Conole's message of "Tue, 10 Mar 2020 13:44:56 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] eal/service: fix exit by resetting service lcores X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Aaron Conole writes: > "Van Haaren, Harry" writes: > >>> -----Original Message----- >>> From: David Marchand >>> Sent: Tuesday, March 10, 2020 4:31 PM >>> To: Van Haaren, Harry >>> Cc: dev ; Aaron Conole >>> Subject: Re: [PATCH] eal/service: fix exit by resetting service lcores >>>=20 >>> On Tue, Mar 10, 2020 at 2:32 PM Harry van Haaren >>> wrote: >>> > >>> > This commit releases all service cores from thier role, >>> > returning them to ROLE_RTE on rte_service_finalize(). >>> > >>> > This may fix an issue relating to the service cores causing >>> > a race-condition on eal_cleanup(), where the service core >>> > could still be executing while the main thread has already >>> > free-d the service memory, leading to a segfault. >>>=20 >>> Adding rte_service_lcore_reset_all() just tells a (remaining) service >>> lcore to quit its loop, but does not close the race on lcore_states. >>>=20 >>> The backtrace shows the same. >>>=20 >>> (gdb) bt full >>> #0 rte_service_runner_func (arg=3D) at >>> ../lib/librte_eal/common/rte_service.c:455 >>> service_mask =3D 1 >>> i =3D >>> lcore =3D 1 >>> cs =3D 0x1003ea200 >>> #1 0x00007ffff72030ef in eal_thread_loop (arg=3D) at >>> ../lib/librte_eal/linux/eal/eal_thread.c:153 >>> fct_arg =3D >>> c =3D 0 '\000' >>> n =3D >>> ret =3D >>> lcore_id =3D >>> thread_id =3D 140737203603200 >>> m2s =3D 14 >>> s2m =3D 22 >>> cpuset =3D "1", '\000' , >>> "\200\000\000\000\000\000\000\000\221\354e\360\377\177", '\000' >>> >>> __func__ =3D "eal_thread_loop" >>> #2 0x00007ffff065ddd5 in start_thread () from /lib64/libpthread.so.0 >>> No symbol table info available. >>> #3 0x00007ffff038702d in clone () from /lib64/libc.so.6 >>> No symbol table info available. >>>=20 >>>=20 >>> I added a rte_eal_mp_wait_lcore(), to ensure that each service lcore >>> _did_ quit its loop. >>> @@ -123,6 +123,7 @@ rte_service_finalize(void) >>> return; >>>=20 >>> rte_service_lcore_reset_all(); >>> + rte_eal_mp_wait_lcore(); >>>=20 >>> rte_free(rte_services); >>> rte_free(lcore_states); >>>=20 >>>=20 >>> I can't reproduce with this. >> >> OK - that's good news, thanks for the quick testing & feedback. >> >> Agree with your analysis of the above, indeed waiting for the cores >> explicitly seems the right solution to remove the race. >> >> Will I spin up a v2 patchset with your co-authored-by added and the abov= e >> change included? > > Please spin the v2 - I am currently testing with David's incremental on > my setup now. Additionally, with the incremental: Acked-by: Aaron Conole Please make sure to cc stable@.