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 327A6A0096 for ; Wed, 5 Jun 2019 11:47:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 08D6B1B9B8; Wed, 5 Jun 2019 11:47:32 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 850512B8E for ; Wed, 5 Jun 2019 11:47:30 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2019 02:47:29 -0700 X-ExtLoop1: 1 Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.94]) ([10.237.220.94]) by fmsmga008.fm.intel.com with ESMTP; 05 Jun 2019 02:47:28 -0700 To: Thomas Monjalon , Erik Gabriel Carrillo Cc: dev@dpdk.org, rsanford@akamai.com, david.marchand@redhat.com References: <1556924082-22535-1-git-send-email-erik.g.carrillo@intel.com> <1557354906-2500-1-git-send-email-erik.g.carrillo@intel.com> <3809be84-8fa7-b91d-d781-f62e0506f293@intel.com> <4234840.t272voWUu0@xps> From: "Burakov, Anatoly" Message-ID: <6fa30d88-c266-5864-8aee-171a2e61d37e@intel.com> Date: Wed, 5 Jun 2019 10:47:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <4234840.t272voWUu0@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3] 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" On 05-Jun-19 10:33 AM, Thomas Monjalon wrote: > 09/05/2019 10:29, Burakov, Anatoly: >> On 08-May-19 11:35 PM, Erik Gabriel Carrillo wrote: >>> By using a lock added to the rte_mem_config (which lives in shared >>> memory), we can synchronize multiple processes in init/finalize and >>> safely free allocations made during init. >>> >>> Signed-off-by: Erik Gabriel Carrillo >>> --- >>> changes in v3: >>> - The previous version had race condition. This version fixes the race >>> by adding a lock in shared memory outside of the DPDK heap area >>> that can be used to safely free the memzone reserved in the subsystem >>> init call. (Anatoly) >>> >>> This patch depends on http://patches.dpdk.org/patch/53333/. >>> >>> changes in v2: >>> - Handle scenario where primary process exits before secondaries such >>> that memzone is not freed early (Anatoly) >>> >>> lib/librte_eal/common/include/rte_eal_memconfig.h | 3 +++ >>> lib/librte_timer/rte_timer.c | 23 ++++++++++++++++++++++- >>> 2 files changed, 25 insertions(+), 1 deletion(-) >>> >>> diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h b/lib/librte_eal/common/include/rte_eal_memconfig.h >>> index 84aabe3..8cbc09c 100644 >>> --- a/lib/librte_eal/common/include/rte_eal_memconfig.h >>> +++ b/lib/librte_eal/common/include/rte_eal_memconfig.h >>> @@ -64,6 +64,9 @@ struct rte_mem_config { >>> rte_rwlock_t memory_hotplug_lock; >>> /**< indicates whether memory hotplug request is in progress. */ >>> >>> + rte_spinlock_t timer_subsystem_lock; >>> + /**< indicates whether timer subsystem init/finalize is in progress. */ >>> + >> >> I believe there's an initialize function somewhere which will initialize >> all of these locks. This lock should be in there as well. >> >> Other than that, i'm OK with this change, however i feel like /just/ >> adding this would be a missed opportunity, because next time we want to >> add something here it will be an ABI break again. >> >> We could perhaps use this opportunity to leave some padding for future >> data. I'm not sure how would that look like, just an idea floating in my >> head :) > > Any update or other opinion? > I have a patchset that hides mem config - if we are to add a lock, it would be after adding that patch, as a bugfix (since by then it would n longer be an ABI breakage or an API change). -- Thanks, Anatoly