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 7674AA0096 for ; Wed, 8 May 2019 10:50:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 69C8434F0; Wed, 8 May 2019 10:50:03 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 36E892C2B for ; Wed, 8 May 2019 10:50:01 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2019 01:50:00 -0700 X-ExtLoop1: 1 Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.21.172]) ([10.252.21.172]) by fmsmga001.fm.intel.com with ESMTP; 08 May 2019 01:49:58 -0700 To: "Carrillo, Erik G" , "rsanford@akamai.com" , "thomas@monjalon.net" Cc: "dev@dpdk.org" References: <1556737217-24338-1-git-send-email-erik.g.carrillo@intel.com> <1556924082-22535-1-git-send-email-erik.g.carrillo@intel.com> <7baed0b9-432f-be86-5e39-68035bc309a4@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Wed, 8 May 2019 09:49:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 v2] timer: fix resource leak in finalize 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: <20190508084958.Ts0xxYRoyBat4APWVPx9PUxUCUCzuGuwFGt77u1DxD4@z> On 07-May-19 11:04 PM, Carrillo, Erik G wrote: > Hi Anatoly, > > Thanks for the review. Comments in-line: > > <...snipped...> > >>> #define RTE_MAX_DATA_ELS 64 >>> +static const struct rte_memzone *rte_timer_data_mz; static >>> +rte_atomic16_t *rte_timer_mz_refcnt; >>> static struct rte_timer_data *rte_timer_data_arr; >>> static const uint32_t default_data_id; >>> static uint32_t rte_timer_subsystem_initialized; @@ -155,6 +157,7 @@ >>> rte_timer_subsystem_init_v1905(void) >>> struct rte_timer_data *data; >>> int i, lcore_id; >>> static const char *mz_name = "rte_timer_mz"; >>> + size_t data_arr_size = RTE_MAX_DATA_ELS * >>> +sizeof(*rte_timer_data_arr); >> >> nitpicking, but... const? >> > > No problem - I'll make this change if this line persists into the next version. > > <...snipped...> > >>> >>> @@ -205,8 +216,11 @@ >> BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05); >>> void __rte_experimental >>> rte_timer_subsystem_finalize(void) >>> { >>> - if (rte_timer_data_arr) >>> - rte_free(rte_timer_data_arr); >>> + if (!rte_timer_subsystem_initialized) >>> + return; >>> + >>> + if (rte_atomic16_dec_and_test(rte_timer_mz_refcnt)) >>> + rte_memzone_free(rte_timer_data_mz); >> >> I think there's a race here. You may get preempted after test but before >> free, where another secondary could initialize. As far as i know, we also > > Indeed, thanks for catching this. > >> support a case when secondary initializes after primary stops running. >> >> Let's even suppose that we allow secondary processes to initialize the timer >> subsystem by reserving memzone and checking rte_errno. You would still >> have a chance of two init/deinit conflicting, because there's a hole between >> memzone allocation and atomic increment. >> >> I don't think this race can be resolved in a safe way, so we might just have to >> settle for a memory leak. >> > > I don't see a solution here currently either. I'll look at removing the memzone_free() > call and possibly the rte_timer_subsystem_finalize() API, since it seems like > there's no reason for it to exist if it can't free the allocations. I wonder if there are other places in DPDK where this pattern is used. Technically, this kind of thing /could/ be resolved by having something in our multiprocess shared memory outside of DPDK heap. I.e. store something in rte_eal_memconfig like some other things do. This change, however, would require an ABI break, so while changing this particular API won't need a deprecation notice, the change itself would. > > Regards, > Erik > >>> >>> rte_timer_subsystem_initialized = 0; >>> } >>> >> >> >> -- >> Thanks, >> Anatoly -- Thanks, Anatoly