[dpdk-stable] patch 'mem: fix munmap in error unwind' has been queued to stable release 19.11.1

[luca.boccassi at gmail.com]

Hi,

FYI, your patch has been queued to stable release 19.11.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 02/13/20. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Thanks.

Luca Boccassi

---
>From 38d2c9ffdfa00563a6da266caba7ac0e55910260 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <stephen at networkplumber.org>
Date: Wed, 22 Jan 2020 09:06:11 -0800
Subject: [PATCH] mem: fix munmap in error unwind

[ upstream commit 292f02b58c26c3bad2327a52c49ec6eff580e124 ]

The loop to unwind existing mmaps was only unmapping the
first segment and the error paths after mmap() were not
doing munmap of the current segment.

Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")

Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>
---
 lib/librte_eal/linux/eal/eal_memory.c | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index 43e4ffc757..5604c2a7c0 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -1928,7 +1928,7 @@ eal_legacy_hugepage_attach(void)
 		if (flock(fd, LOCK_SH) < 0) {
 			RTE_LOG(DEBUG, EAL, "%s(): Locking file failed: %s\n",
 				__func__, strerror(errno));
-			goto fd_error;
+			goto mmap_error;
 		}
 
 		/* find segment data */
@@ -1936,13 +1936,13 @@ eal_legacy_hugepage_attach(void)
 		if (msl == NULL) {
 			RTE_LOG(DEBUG, EAL, "%s(): Cannot find memseg list\n",
 				__func__);
-			goto fd_error;
+			goto mmap_error;
 		}
 		ms = rte_mem_virt2memseg(map_addr, msl);
 		if (ms == NULL) {
 			RTE_LOG(DEBUG, EAL, "%s(): Cannot find memseg\n",
 				__func__);
-			goto fd_error;
+			goto mmap_error;
 		}
 
 		msl_idx = msl - mcfg->memsegs;
@@ -1950,7 +1950,7 @@ eal_legacy_hugepage_attach(void)
 		if (ms_idx < 0) {
 			RTE_LOG(DEBUG, EAL, "%s(): Cannot find memseg idx\n",
 				__func__);
-			goto fd_error;
+			goto mmap_error;
 		}
 
 		/* store segment fd internally */
@@ -1963,18 +1963,15 @@ eal_legacy_hugepage_attach(void)
 	close(fd_hugepage);
 	return 0;
 
+mmap_error:
+	munmap(hp[i].final_va, hp[i].size);
 fd_error:
 	close(fd);
 error:
-	/* map all segments into memory to make sure we get the addrs */
-	cur_seg = 0;
-	for (cur_seg = 0; cur_seg < i; cur_seg++) {
-		struct hugepage_file *hf = &hp[i];
-		size_t map_sz = hf->size;
-		void *map_addr = hf->final_va;
+	/* unwind mmap's done so far */
+	for (cur_seg = 0; cur_seg < i; cur_seg++)
+		munmap(hp[cur_seg].final_va, hp[cur_seg].size);
 
-		munmap(map_addr, map_sz);
-	}
 	if (hp != NULL && hp != MAP_FAILED)
 		munmap(hp, size);
 	if (fd_hugepage >= 0)
-- 
2.20.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2020-02-11 11:17:45.060093444 +0000
+++ 0189-mem-fix-munmap-in-error-unwind.patch	2020-02-11 11:17:38.840009574 +0000
@@ -1,14 +1,15 @@
-From 292f02b58c26c3bad2327a52c49ec6eff580e124 Mon Sep 17 00:00:00 2001
+From 38d2c9ffdfa00563a6da266caba7ac0e55910260 Mon Sep 17 00:00:00 2001
 From: Stephen Hemminger <stephen at networkplumber.org>
 Date: Wed, 22 Jan 2020 09:06:11 -0800
 Subject: [PATCH] mem: fix munmap in error unwind
 
+[ upstream commit 292f02b58c26c3bad2327a52c49ec6eff580e124 ]
+
 The loop to unwind existing mmaps was only unmapping the
 first segment and the error paths after mmap() were not
 doing munmap of the current segment.
 
 Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")
-Cc: stable at dpdk.org
 
 Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
 Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>