From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7B729A054F; Mon, 1 Mar 2021 11:44:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3B41122A240; Mon, 1 Mar 2021 11:44:43 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 3D4074067B; Mon, 1 Mar 2021 11:44:41 +0100 (CET) IronPort-SDR: FjhOTMATANO8T7iEETrwNn24XGap//mEZP5tzdAlfBRF+z/9B/gIO/bId33WAKLkGgN7+W51WF cM7maJUKRnDQ== X-IronPort-AV: E=McAfee;i="6000,8403,9909"; a="250475918" X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="250475918" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 02:44:40 -0800 IronPort-SDR: GXKPXANCiKeE90juTHorkuHciQO7DrZvi2+rbAHMCN6gXL7bkOdZgpWAgTx2L3zcU/hfXaWNAj R/x0cCTsWQeA== X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="397669263" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.224.194]) ([10.213.224.194]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 02:44:38 -0800 To: Roy Shterman Cc: dev@dpdk.org, Yuval Mintz , Aviv Ben David , dpdk stable References: <20210222104131.11979-1-roy.shterman@vastdata.com> From: "Burakov, Anatoly" Message-ID: Date: Mon, 1 Mar 2021 10:44:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] mem: fix free segment when using huge-unlink option X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 28-Feb-21 1:21 PM, Roy Shterman wrote: > > > On Mon, Feb 22, 2021 at 5:53 PM Burakov, Anatoly > > wrote: > > On 22-Feb-21 10:41 AM, Roy Shterman wrote: > > When using huge_unlink we unlink the segment right > > after allocation. Although we unlink the file we keep > > the fd in fd_list so file still exist just the path deleted. > > When freeing the hugepage we need to close the fd and assign > > it with (-1) in fd_list for the page to be released. > > > > The current flow fails rte_malloc in the following flow when working > > with --huge-unlink option: > > 1. alloc_seg() for segment A - > >      We allocate segment, unlink the path to the segment > >      and keep the file descriptor in fd_list. > > 2. free_seg() for segment A - > >      We clear the segment metadata and return - without closing fd > >      or assigning (-1) in fd list. > > 3. alloc_seg() for segment A again - > >      We find segment A as available, try to allocate it, > >      find the old fd in fd_list try to unlink it > >      as part of alloc_seg() but failed because path doesn't exist. > > > > The impact of such error is falsly failing rte_malloc() > > although we have hugepages available. > > > > Fixes: d435aad37da7 ("mem: support --huge-unlink mode") > > > > Signed-off-by: Roy Shterman > > > Cc: stable@dpdk.org > > Provisionally, patch looks fine, but i'll have to have a closer look. > > > Hi Anatoly, > > Do I need to send this patch also to stable or it will happen > automatically if the patch will reach the next release candidate? Not automatically, generally you should add a CC to stable for the patch to be considered as part of stable release. That said, usually Fixed: tag is also used to determine whether a patch is backport-able, so having a correctly identified Fixed: tag is a mandatory minimum :) > Also I wonder if you had more time to review this one? Not yet, but i'll try to make some time this week. > > > -- > Thanks, > Anatoly > > > Thanks, > Roy -- Thanks, Anatoly