[dpdk-stable] [PATCH 2/3] eal: reorder calling munmap on zero-mapped memory

[Gowrishankar]

From: Gowrishankar Muthukrishnan <gowrishankar.m at linux.vnet.ibm.com>

In the current code path where secondary processes attaches memory
mapped area that primary process created, it releases one by one
zero-mapped memory in VA for the length of every iterated rte_memseg.
PowerPC mm would not be able to respect address hint as secondary
process would later ask to mmap hugepages in this freed area.
For powerpc mm to respect address hint, its entire underlying memory
slice (of about 1 TB in VA) should have been freed before re-mapping
requested. So, we move this munmap() slightly above, from its current
calling place so that, entire zero mapped area is alredy freed.

Fixes: 284ae3e9ff ("eal/ppc: fix mmap for memory initialization")
Cc: stable at dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan <gowrishankar.m at linux.vnet.ibm.com>
---
 lib/librte_eal/linuxapp/eal/eal_memory.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 2dcb3b5..3dcd6c2 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1428,6 +1428,11 @@ void numa_error(char *where)
 			}
 			goto error;
 		}
+		/*
+		 * free previously mapped memory so we can map the
+		 * hugepages into this space shortly
+		 */
+		munmap(base_addr, mcfg->memseg[s].len);
 	}
 
 	size = getFileSize(fd_hugepage);
@@ -1445,12 +1450,7 @@ void numa_error(char *where)
 		void *addr, *base_addr;
 		uintptr_t offset = 0;
 		size_t mapping_size;
-		/*
-		 * free previously mapped memory so we can map the
-		 * hugepages into the space
-		 */
 		base_addr = mcfg->memseg[s].addr;
-		munmap(base_addr, mcfg->memseg[s].len);
 
 		/* find the hugepages for this segment and map them
 		 * we don't need to worry about order, as the server sorted the
-- 
1.9.1