From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id CFD75A00E6 for ; Wed, 20 Mar 2019 11:50:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 987C44F91; Wed, 20 Mar 2019 11:50:26 +0100 (CET) Received: by dpdk.org (Postfix, from userid 33) id 10EE14F91; Wed, 20 Mar 2019 11:50:26 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Wed, 20 Mar 2019 10:50:26 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: dariusz.stojaczyk@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://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 228] rte_mp_request_sync memleak with multiple recipients 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" Message-ID: <20190320105026.qLa1KOCdad-qEKQ3Soc0KcopSdHNJFHj-7OxcfKUomc@z> https://bugs.dpdk.org/show_bug.cgi?id=3D228 Bug ID: 228 Summary: rte_mp_request_sync memleak with multiple recipients Product: DPDK Version: unspecified Hardware: All OS: All Status: CONFIRMED Severity: minor Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: dariusz.stojaczyk@intel.com Target Milestone: --- When sending multiple requests, rte_mp_request_sync can succeed sending a few of those requests, but then fail on a later one and in the end return with rc=3D-1. The upper layers - e.g. device hotplug - currently handles this case as if no messages were sent and no memory for response buffers was allocated, which is not true. Fixing the above is not so obvious, as rte_mp_request_sync can fail before the response buffer pointer is even set (it is unitialized by default). So the caller cannot safely access it (or free it) just if the function returns with rc=3D-1. One way to fix this is to always initialize the response buffer pointer and always require the caller to free the response buffer. This, however, asks for a redesign and should be addressed with slightly more effort put into it. Maybe the response buffer pointer should be initialized by the caller from the very beginning? --=20 You are receiving this mail because: You are the assignee for the bug.=