From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH] member: fix memory leak on error Date: Sat, 23 Dec 2017 11:55:17 +0000 Message-ID: References: <5c0a540f8917604a86e18f8da77fa0c2013b7fde.1513865858.git.anatoly.burakov@intel.com> <08f1736c-e3ce-1dfd-02a1-032f990472d1@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Gobriel, Sameh" To: "Wang, Yipeng1" , "dev@dpdk.org" Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 4719F1B2A2 for ; Sat, 23 Dec 2017 12:55:20 +0100 (CET) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 22-Dec-17 6:33 PM, Wang, Yipeng1 wrote: >> -----Original Message----- >> From: Burakov, Anatoly >> Yep, i can see that now. Didn't think to look inside rte_member_free() >> :/ However, you're creating a race condition there - you're unlocking a >> tailq, and then locking (and unlocking) it again inside >> rte_member_free() - it probably needs _thread_unsafe() functions that >> you can call from behind the lock. >> >> -- > > Thank you Anatoly, > > I realize that rte_member_free does not do anything good here. As a fix, I think the following should work. Is there any other concern? > Yes, that should work. Table creation is the last step that can cause an error, so if we're there, we already know that we couldn't have allocated it, so there's no need to deallocate those, and simple rte_free(setsum) should do. I'll submit a v2? -- Thanks, Anatoly