From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id 512B123D for ; Mon, 30 Jul 2018 18:21:41 +0200 (CEST) Received: from 1.general.paelzer.uk.vpn ([10.172.196.172] helo=lap.fritz.box) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1fkArP-00009D-MD; Mon, 30 Jul 2018 16:17:27 +0000 From: Christian Ehrhardt To: Dariusz Stojaczyk Cc: Anatoly Burakov , dpdk stable Date: Mon, 30 Jul 2018 18:12:30 +0200 Message-Id: <20180730161342.16566-105-christian.ehrhardt@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180730161342.16566-1-christian.ehrhardt@canonical.com> References: <20180730161342.16566-1-christian.ehrhardt@canonical.com> Subject: [dpdk-stable] patch 'mem: do not unmap overlapping region on mmap failure' has been queued to stable release 18.05.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 16:21:41 -0000 Hi, FYI, your patch has been queued to stable release 18.05.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 08/01/18. So please shout if anyone has objections. Thanks. Christian Ehrhardt --- >>From ca9746df21edfc99ef63bce5f24c8762d5a98add Mon Sep 17 00:00:00 2001 From: Dariusz Stojaczyk Date: Fri, 1 Jun 2018 14:59:20 +0200 Subject: [PATCH] mem: do not unmap overlapping region on mmap failure [ upstream commit 0762c438b8da8486b283f4da0c01a85f684b8896 ] This isn't documented in the manuals, but a failed mmap(..., MAP_FIXED) may still unmap overlapping regions. In such case, we need to remap these regions back into our address space to ensure mem contiguity. We do it unconditionally now on mmap failure just to be safe. Verified on Linux 4.9.0-4-amd64. I was getting ENOMEM when trying to map hugetlbfs with no space left, and the previous anonymous mapping was still being removed. Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime") Signed-off-by: Dariusz Stojaczyk Acked-by: Anatoly Burakov --- lib/librte_eal/linuxapp/eal/eal_memalloc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c index 6be668055..81c94d54e 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c +++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c @@ -527,7 +527,10 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, if (va == MAP_FAILED) { RTE_LOG(DEBUG, EAL, "%s(): mmap() failed: %s\n", __func__, strerror(errno)); - goto resized; + /* mmap failed, but the previous region might have been + * unmapped anyway. try to remap it + */ + goto unmapped; } if (va != addr) { RTE_LOG(DEBUG, EAL, "%s(): wrong mmap() address\n", __func__); @@ -588,6 +591,7 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, mapped: munmap(addr, alloc_sz); +unmapped: flags = MAP_FIXED; #ifdef RTE_ARCH_PPC_64 flags |= MAP_HUGETLB; -- 2.17.1