> From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, January 31, 2018 2:32 PM > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Van Haaren, Harry > <harry.van.haa...@intel.com> > Cc: dev@dpdk.org; pbhagavat...@caviumnetworks.com > Subject: Re: [dpdk-dev] [PATCH v2] test: fix debug autotest with eal cleanup > addition > > 31/01/2018 14:53, Ananyev, Konstantin: > > Hi Harry, > > > > From: Harry van Haaren > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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_finalize() or so. > > Konstantin
Valid concerns, the issue gets complex when we mix shared resources and fork() multiple processes, threads etc. > At first, we should discuss whether it is a good idea to support fork, > given that we have the "secondary process solution". > > Then, if an improvement is needed, it should go in 18.05. > I think the fix in UT is good enough for 18.02. Agreed, and I'd prefer not rush changes here given the complexity and multitude of use-cases.
