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 31F275B3A for ; Mon, 30 Jul 2018 18:22:28 +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 1fkArO-00009D-OP; Mon, 30 Jul 2018 16:17:26 +0000 From: Christian Ehrhardt To: Dariusz Stojaczyk Cc: Anatoly Burakov , dpdk stable Date: Mon, 30 Jul 2018 18:12:29 +0200 Message-Id: <20180730161342.16566-104-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 leave unmapped holes in EAL memory area' 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:22:28 -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 417fa405f8b549e2caf22b377260dc232f411da3 Mon Sep 17 00:00:00 2001 From: Dariusz Stojaczyk Date: Fri, 1 Jun 2018 14:59:19 +0200 Subject: [PATCH] mem: do not leave unmapped holes in EAL memory area [ upstream commit 637175ab95ed1dad3790a3c565fe8eaf422aa2c3 ] EAL reserves a huge area in virtual address space to provide virtual address contiguity for e.g. future memory extensions (memory hotplug). During memory hotplug, if the hugepage mmap succeeds but doesn't suffice EAL's requiriments, the EAL would unmap this mapping straight away, leaving a hole in its virtual memory area and making it available to everyone. As EAL still thinks it owns the entire region, it may try to mmap it later with MAP_FIXED, possibly overriding a user's mapping that was made in the meantime. This patch ensures each hole is mapped back by EAL, so that it won't be available to anyone else. 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 | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c index 8c11f98c9..6be668055 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c +++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c @@ -39,6 +39,7 @@ #include "eal_filesystem.h" #include "eal_internal_cfg.h" #include "eal_memalloc.h" +#include "eal_private.h" /* * not all kernel version support fallocate on hugetlbfs, so fall back to @@ -490,6 +491,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, int ret = 0; int fd; size_t alloc_sz; + int flags; + void *new_addr; /* takes out a read lock on segment or segment list */ fd = get_seg_fd(path, sizeof(path), hi, list_idx, seg_idx); @@ -585,6 +588,20 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, mapped: munmap(addr, alloc_sz); + flags = MAP_FIXED; +#ifdef RTE_ARCH_PPC_64 + flags |= MAP_HUGETLB; +#endif + new_addr = eal_get_virtual_area(addr, &alloc_sz, alloc_sz, 0, flags); + if (new_addr != addr) { + if (new_addr != NULL) + munmap(new_addr, alloc_sz); + /* we're leaving a hole in our virtual address space. if + * somebody else maps this hole now, we could accidentally + * override it in the future. + */ + RTE_LOG(CRIT, EAL, "Can't mmap holes in our virtual address space\n"); + } resized: if (internal_config.single_file_segments) { resize_hugefile(fd, path, list_idx, seg_idx, map_offset, -- 2.17.1