From patchwork Mon Feb 22 10:41:31 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roy Shterman X-Patchwork-Id: 88101 X-Patchwork-Delegate: david.marchand@redhat.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8B3D8A034F; Tue, 23 Feb 2021 09:05:17 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4D77F4067A; Tue, 23 Feb 2021 09:05:17 +0100 (CET) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by mails.dpdk.org (Postfix) with ESMTP id 6BEDD4003C for ; Mon, 22 Feb 2021 11:41:47 +0100 (CET) Received: by mail-ed1-f54.google.com with SMTP id l12so21243914edt.3 for ; Mon, 22 Feb 2021 02:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vastdata.com; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=5As5oXLjvtk1IENtBiEE4eNzBJBNdMbyKud2CusGl54=; b=EG38JR3I5tO+v13A6404QQJrTt8Ug+LWKj0fbDRvuK8elOW9epz64m39ozawpKt31R a9qYVJqLO/zCzqCS8jOXMlf/ivstfLj5H+QxamrsV/GhLBm6ha4HNu6xpQcKcqi5SZBr 3v5zm/D9uhdCrEOIWhk1BFn6K92tKatrYd6Ju7QwqS0KK1drnEY1pyCba6Z1PaoSgwHE sNDGhjqEUQ1tz/mA57bZYnTg9mQit9xRjAarLyBl2iGEN2LiwOBZfqqkqToMZ8wnTEQC RY086mkjbdTsmrGSzD9jCUj01FUOz9c1R4WxcRmsH4+Y+YUQyBOTo/ucSG3V7v0i8n3Z PusQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=5As5oXLjvtk1IENtBiEE4eNzBJBNdMbyKud2CusGl54=; b=hOxBLQyoqM9Jc/tfhC1/QZPzC7x9Vb1CiC3ycekVizg0/Yu2ubb1djQYw8bCzYYr4T +A5TMeeCVd4xw4i7kanKk2Ipyt1K9T/kAWji7vn6oJ2Woe/Xayrli2E7HrVR6GeJBIm7 4N1QI5B8klYErPPWtH5bn99baRFtTC99Q5gwdLBQQwhr4Ht7eUMfRMiYlSPu6CwLyeg1 tVjrbjUehDwDcREkrBTwn/IC27dqQdDRn6zzlzXeIRpJu3oQzTHUhSDja7Di8gCdsMuM 7j4jCyK/30TeBkz+Jpd6zrgc5qjzbhw6C93wyjFcRsYFGp0b22w1VliWMMpHkL78aTGu DVnA== X-Gm-Message-State: AOAM533SjcnTbk13/hVn77l5e5Nm3TT2LNmtI14z8vdpSuJkD4QG5ayl VFleVdj4JpkB5U/h51fXa6xMpA== X-Google-Smtp-Source: ABdhPJxuO7Z67ZWhvHhHT2tpA+nqdJb0wbo+Ao5Bli8VlsCLxG3bdg0z9X7dwqC6WeBgh1MjS5tAkQ== X-Received: by 2002:aa7:c94c:: with SMTP id h12mr22337069edt.40.1613990507072; Mon, 22 Feb 2021 02:41:47 -0800 (PST) Received: from localhost.localdomain (93-173-132-167.bb.netvision.net.il. [93.173.132.167]) by smtp.gmail.com with ESMTPSA id d6sm1390237ejr.59.2021.02.22.02.41.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2021 02:41:46 -0800 (PST) From: Roy Shterman To: anatoly.burakov@intel.com Cc: dev@dpdk.org, yuval@vastdata.com, aviv.bendavid@vastdata.com, Roy Shterman Date: Mon, 22 Feb 2021 12:41:31 +0200 Message-Id: <20210222104131.11979-1-roy.shterman@vastdata.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 23 Feb 2021 09:05:16 +0100 Subject: [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" 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 --- lib/librte_eal/linux/eal_memalloc.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/lib/librte_eal/linux/eal_memalloc.c b/lib/librte_eal/linux/eal_memalloc.c index 6dc1b2bae..c590d6043 100644 --- a/lib/librte_eal/linux/eal_memalloc.c +++ b/lib/librte_eal/linux/eal_memalloc.c @@ -709,7 +709,6 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, uint64_t map_offset; char path[PATH_MAX]; int fd, ret = 0; - bool exit_early; const struct internal_config *internal_conf = eal_get_internal_configuration(); @@ -725,17 +724,8 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, eal_mem_set_dump(ms->addr, ms->len, false); - exit_early = false; - /* if we're using anonymous hugepages, nothing to be done */ - if (internal_conf->in_memory && !memfd_create_supported) - exit_early = true; - - /* if we've already unlinked the page, nothing needs to be done */ - if (!internal_conf->in_memory && internal_conf->hugepage_unlink) - exit_early = true; - - if (exit_early) { + if (internal_conf->in_memory && !memfd_create_supported) { memset(ms, 0, sizeof(*ms)); return 0; } @@ -761,7 +751,7 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, /* if we're able to take out a write lock, we're the last one * holding onto this page. */ - if (!internal_conf->in_memory) { + if (!internal_conf->in_memory && !internal_conf->hugepage_unlink) { ret = lock(fd, LOCK_EX); if (ret >= 0) { /* no one else is using this page */