From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 600E6AAEC for ; Fri, 27 Apr 2018 19:07:14 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2018 10:07:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,335,1520924400"; d="scan'208";a="49675604" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga004.fm.intel.com with ESMTP; 27 Apr 2018 10:07:12 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id w3RH7Bkn026441; Fri, 27 Apr 2018 18:07:11 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id w3RH7Bwd023488; Fri, 27 Apr 2018 18:07:11 +0100 Received: (from aburakov@localhost) by sivswdev01.ir.intel.com with LOCAL id w3RH7BuQ023484; Fri, 27 Apr 2018 18:07:11 +0100 From: Anatoly Burakov To: dev@dpdk.org Cc: thomas@monjalon.net, bruce.richardson@intel.com, anatoly.burakov@intel.com Date: Fri, 27 Apr 2018 18:07:05 +0100 Message-Id: <7012a05f7f10b0c71ef742ba3caf2e86504f8646.1524848343.git.anatoly.burakov@intel.com> X-Mailer: git-send-email 1.7.0.7 In-Reply-To: References: In-Reply-To: References: Subject: [dpdk-dev] [PATCH v4 4/9] mem: fix potential resource leak 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: , X-List-Received-Date: Fri, 27 Apr 2018 17:07:15 -0000 We close fd if we managed to find it in the list of allocated segment lists (which should always be the case under normal conditions), but if we didn't, the fd was leaking. Close it if we couldn't find it in the segment list. This is not an issue as if the segment is zero length, we're getting rid of it anyway, so there's no harm in not storing the fd anywhere. Coverity issue: 272568 Fixes: 2a04139f66b4 ("eal: add single file segments option") Cc: anatoly.burakov@intel.com Signed-off-by: Anatoly Burakov Acked-by: Bruce Richardson --- Notes: v4: - Unconditionally close fd - Added comments explaining what happens if we don't remove the file lib/librte_eal/linuxapp/eal/eal_memalloc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c index 3391ed1..5ea6dd3 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c +++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c @@ -567,12 +567,13 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, */ if (is_zero_length(fd)) { struct msl_entry *te = get_msl_entry_by_idx(list_idx); - if (te != NULL && te->fd >= 0) { - close(te->fd); + /* te->fd is equivalent to fd */ + if (te != NULL && te->fd >= 0) te->fd = -1; - } unlink(path); + close(fd); } + /* if we're not removing the file, fd stays in the tailq */ ret = 0; } else { /* if we're able to take out a write lock, we're the last one -- 2.7.4