From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 46C991B7B4 for ; Wed, 31 Jan 2018 14:53:18 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 05:53:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,440,1511856000"; d="scan'208";a="23853095" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by FMSMGA003.fm.intel.com with ESMTP; 31 Jan 2018 05:53:16 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.197]) by irsmsx105.ger.corp.intel.com ([169.254.7.221]) with mapi id 14.03.0319.002; Wed, 31 Jan 2018 13:53:15 +0000 From: "Ananyev, Konstantin" To: "Van Haaren, Harry" , "dev@dpdk.org" CC: "pbhagavatula@caviumnetworks.com" , "Van Haaren, Harry" , "thomas@monjalon.net" Thread-Topic: [dpdk-dev] [PATCH v2] test: fix debug autotest with eal cleanup addition Thread-Index: AQHTmffcCzmme4SrzEyRpbCzD6ufOqON/evA Date: Wed, 31 Jan 2018 13:53:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258905663C3@IRSMSX103.ger.corp.intel.com> References: <1517336497-17943-1-git-send-email-harry.van.haaren@intel.com> <1517336769-18052-1-git-send-email-harry.van.haaren@intel.com> In-Reply-To: <1517336769-18052-1-git-send-email-harry.van.haaren@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGRmNTI2ZDUtYzBmNS00YzJlLWEzNmEtZGU0YjU2MGU0N2MyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjJmYU1PdENGcmxUXC95UEhlSmZkSm04S2tJMjBEUFhWczFcL28rR3c4SXJUST0ifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] test: fix debug autotest with eal cleanup addition 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: , X-List-Received-Date: Wed, 31 Jan 2018 13:53:18 -0000 Hi Harry, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Harry van Haaren > Sent: Tuesday, January 30, 2018 6:26 PM > To: dev@dpdk.org > Cc: pbhagavatula@caviumnetworks.com; Van Haaren, Harry ; thomas@monjalon.net > Subject: [dpdk-dev] [PATCH v2] test: fix debug autotest with eal cleanup = addition >=20 > Before this patch, the debug_autotest would call fork(), > call rte_panic() or rte_exit() in the child process, and > examine the return code to verify that rte_panic() and > rte_exit() were correctly reporting failures. >=20 > With the inclusion of the rte_eal_cleanup() patch, rte_exit() > was modified to cleanly tear-down EAL allocations. Currently > only one library (service cores) is allocated by EAL at startup > and should be cleaned up. This library has a check on a normal > (non-hugepage) variable to protect against double cleanup. The > service cores finalize() function itself frees back hugepage mem. >=20 > Given the fork() approach from the unit test, and the fact that > the double-free check is on an ordinary variable, causes multiple > child processed (fork()-ed from the unit-test runner) to attempt > to free the huge-page memory multiple times. The variable to > protect against double-cleanup was not effective, as the fork() > would restore it to show initialized in the next child. >=20 > The solution is to call rte_service_finalize() *before* calling > fork(), which results in the service cores double-cleanup variable > to be zero before the fork(), and hence the child processes never > free the hugepage service-cores memory (correct behavior, as the > unit-test suite is still running, and owns the hugepages). Ok, you fixed it in UT, but what to do other apps that use fork()? Let say our examples/multi_process/l2fwd_fork uses fork() to spawn child processes instead of threads. Might be some generic way is needed: let say at fork time setup some global to indicate that it is a child process and it shouldn't call rte_fin= alize() or so. Konstantin >=20 > Fixes: aec9c13c5257 ("eal: add function to release internal resources") >=20 > Reported-by: Pavan Nikhilesh > Signed-off-by: Harry van Haaren >=20 > --- >=20 > v2: > - Fix 2 typo/spello mistakes in commit message >=20 > Cc: thomas@monjalon.net >=20 > Please consider for including in RC2 as this fixes the > currently failing debug_autotest. >=20 > --- > test/test/test_debug.c | 6 ++++++ > 1 file changed, 6 insertions(+) >=20 > diff --git a/test/test/test_debug.c b/test/test/test_debug.c > index dd0de44..faf2cf5 100644 > --- a/test/test/test_debug.c > +++ b/test/test/test_debug.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include >=20 > #include "test.h" >=20 > @@ -50,6 +51,11 @@ test_exit_val(int exit_val) > int pid; > int status; >=20 > + /* manually cleanup EAL memory, as the fork() below would otherwise > + * cause the same hugepages to be free()-ed multiple times. > + */ > + rte_service_finalize(); > + > pid =3D fork(); >=20 > if (pid =3D=3D 0) > -- > 2.7.4