From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2017 03:55:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,446,1508828400"; d="scan'208";a="14667304" Received: from mpaulett-mobl5.ger.corp.intel.com (HELO [10.252.20.236]) ([10.252.20.236]) by orsmga003.jf.intel.com with ESMTP; 23 Dec 2017 03:55:18 -0800 To: "Wang, Yipeng1" , "dev@dpdk.org" Cc: "Gobriel, Sameh" References: <5c0a540f8917604a86e18f8da77fa0c2013b7fde.1513865858.git.anatoly.burakov@intel.com> <08f1736c-e3ce-1dfd-02a1-032f990472d1@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Sat, 23 Dec 2017 11:55:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] member: fix memory leak on error 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: Sat, 23 Dec 2017 11:55:21 -0000 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