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 9A8AEA0548; Thu, 1 Apr 2021 13:07:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 37204141060; Thu, 1 Apr 2021 13:07:47 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 6EF164067B for ; Thu, 1 Apr 2021 13:07:45 +0200 (CEST) IronPort-SDR: adrQU7FTbmc1YkwKXp9q7U6mEszNler3vbhw32kyOHLjDhgQ+3zHMZ+UtQM9pIKRwj1GvmSMxt 6ZJ/lsSjkRSw== X-IronPort-AV: E=McAfee;i="6000,8403,9940"; a="179349767" X-IronPort-AV: E=Sophos;i="5.81,296,1610438400"; d="scan'208";a="179349767" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2021 04:07:39 -0700 IronPort-SDR: 9W+UV8qVswIhX/FUBb4uwb2i1h4mwWwjal9iJAZO/BngO/iHlc6gVflhlB3pdW8Ew2eUoxUhvN vjKspCdxK4lQ== X-IronPort-AV: E=Sophos;i="5.81,296,1610438400"; d="scan'208";a="596295976" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.250.93]) ([10.213.250.93]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2021 04:07:27 -0700 To: Roy Shterman Cc: dev@dpdk.org, yuval@vastdata.com, aviv.bendavid@vastdata.com References: <20210222104131.11979-1-roy.shterman@vastdata.com> From: "Burakov, Anatoly" Message-ID: <63d59764-3a86-6b7d-97c3-28a8d1a6eebb@intel.com> Date: Thu, 1 Apr 2021 12:07:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210222104131.11979-1-roy.shterman@vastdata.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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 > --- Acked-by: Anatoly Burakov -- Thanks, Anatoly