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 99711A034F; Mon, 22 Feb 2021 16:53:54 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1514340041; Mon, 22 Feb 2021 16:53:54 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 8F48E4003C for ; Mon, 22 Feb 2021 16:53:51 +0100 (CET) IronPort-SDR: BQzXpqQHc0WQe5ttCaFx+mJFPw6muQ+S4krjllOxY9D5Nie/jiqTBtI1U9O7YSuUNXDeiNPPur le/bFKHV+0fQ== X-IronPort-AV: E=McAfee;i="6000,8403,9903"; a="184600132" X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="184600132" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 07:53:50 -0800 IronPort-SDR: 9WGv3jwGMJMjBNd8BzSluAJH75l1pkURqKne5Ba1f/dYjxJB3zZxZ4GBkSXr6puC7oQ+o13ycJ 5bVNvmntT7Og== X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="432121536" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.233.52]) ([10.213.233.52]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 07:53:48 -0800 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: Date: Mon, 22 Feb 2021 15:53:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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 Cc: stable@dpdk.org Provisionally, patch looks fine, but i'll have to have a closer look. -- Thanks, Anatoly