From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by dpdk.org (Postfix, from userid 33) id D054C1DA4; Tue, 22 May 2018 18:15:47 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Tue, 22 May 2018 16:15:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: core X-Bugzilla-Version: 18.05 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anatoly.burakov@intel.com X-Bugzilla-Status: CONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://dpdk.org/tracker/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 50] Secondary process launch is unreliable 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: Tue, 22 May 2018 16:15:48 -0000 https://dpdk.org/tracker/show_bug.cgi?id=3D50 Bug ID: 50 Summary: Secondary process launch is unreliable Product: DPDK Version: 18.05 Hardware: All OS: All Status: CONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: anatoly.burakov@intel.com Target Milestone: --- Secondary process initialization was known to be unreliable before, with numerous workarounds already being available and documented. However, DPDK version 18.05 has introduced memory subsystem rework, which has made situat= ion worse due to much more memory being pre-reserved at initialization. In addition, following investigation, it was revealed that DPDK secondary processes ran with fork()/execv() method from within another DPDK applicati= on (such as is the case with some DPDK unit tests) carry an additional risk of initialization failures due to how pthread library appears to be working un= der these conditions. Specifically, two IPC threads created by EAL will take up= a lot of address space (more than 10x of the usual amount), thereby interferi= ng with secondary process mappings and causing initialization failure. In this case, disabling ASLR may actually make the situation worse, as non-deterministic but sometimes lucky memory layout will be replaced by deterministically wrong address mappings. Things to try when affected by this issue: * Using --base-virtaddr to relocate DPDK memory segments at initialization * Not running DPDK applications using fork()/execv() method * Enabling or disabling ASLR * Recompiling the binary with different configuration * Reducing the amount of preallocated memory (adjusting config options CONFIG_RTE_MAX_MEM_MB_PER_TYPE and/or RTE_MAX_MEM_MB_PER_LIST) --=20 You are receiving this mail because: You are the assignee for the bug.=