* [dpdk-dev] [PATCH 1/2] mem: fix IVSHMEM
@ 2015-08-07 15:27 Sergio Gonzalez Monroy
2015-08-07 15:27 ` [dpdk-dev] [PATCH 2/2] mem: fix freeing an IVSHMEM memzone Sergio Gonzalez Monroy
0 siblings, 1 reply; 3+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-08-07 15:27 UTC (permalink / raw)
To: dev
After the changes introduced by Dynamic Memzones, all the memsegs were
added to the malloc heap during init.
Those changes did not account for IVSHMEM memsegs which should not be
added to the malloc heap as part of available memory.
Fixes: fafcc11985a2 ("mem: rework memzone to be allocated by malloc")
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
lib/librte_eal/common/malloc_heap.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c
index 21d8914..d170d03 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -220,8 +220,17 @@ rte_eal_malloc_heap_init(void)
for (ms = &mcfg->memseg[0], ms_cnt = 0;
(ms_cnt < RTE_MAX_MEMSEG) && (ms->len > 0);
- ms_cnt++, ms++)
+ ms_cnt++, ms++) {
+#ifdef RTE_LIBRTE_IVSHMEM
+ /*
+ * if segment has ioremap address set, it's an IVSHMEM segment and
+ * it is not memory to allocate from.
+ */
+ if (ms->ioremap_addr != 0)
+ continue;
+#endif
malloc_heap_add_memseg(&mcfg->malloc_heaps[ms->socket_id], ms);
+ }
return 0;
}
--
1.9.3
^ permalink raw reply [flat|nested] 3+ messages in thread
* [dpdk-dev] [PATCH 2/2] mem: fix freeing an IVSHMEM memzone
2015-08-07 15:27 [dpdk-dev] [PATCH 1/2] mem: fix IVSHMEM Sergio Gonzalez Monroy
@ 2015-08-07 15:27 ` Sergio Gonzalez Monroy
2015-08-10 13:40 ` Thomas Monjalon
0 siblings, 1 reply; 3+ messages in thread
From: Sergio Gonzalez Monroy @ 2015-08-07 15:27 UTC (permalink / raw)
To: dev
There is no sync between host and guest to allow removal of memzones,
and freeing them result in undefined behavior.
In the guest, we identify IVSHMEM memsegs/memzones by having
ioremap_addr != 0. In the host, nothing is done to the memzone, meaning
ioremap_addr == 0.
As a solution, mark memzones being added to IVSHMEM in the host, by
setting ioremap_addr, then return an error whenever we try to free an
IVSHMEM memzone.
Fixes: ff909fe21f0 ("mem: introduce memzone freeing")
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
---
lib/librte_eal/common/eal_common_memzone.c | 8 ++++++++
lib/librte_eal/common/include/rte_memzone.h | 4 +++-
lib/librte_ivshmem/rte_ivshmem.c | 15 +++++++++++++++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_memzone.c b/lib/librte_eal/common/eal_common_memzone.c
index 7b1d77e..febc56b 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -322,6 +322,14 @@ rte_memzone_free(const struct rte_memzone *mz)
idx = idx / sizeof(struct rte_memzone);
addr = mcfg->memzone[idx].addr;
+#ifdef RTE_LIBRTE_IVSHMEM
+ /*
+ * If ioremap_addr is set, it's an IVSHMEM memzone and we cannot
+ * free it.
+ */
+ if (mcfg->memzone[idx].ioremap_addr != 0)
+ ret = -EINVAL;
+#endif
if (addr == NULL)
ret = -EINVAL;
else if (mcfg->memzone_cnt == 0) {
diff --git a/lib/librte_eal/common/include/rte_memzone.h b/lib/librte_eal/common/include/rte_memzone.h
index 38e5f5b..6a92222 100644
--- a/lib/librte_eal/common/include/rte_memzone.h
+++ b/lib/librte_eal/common/include/rte_memzone.h
@@ -258,10 +258,12 @@ const struct rte_memzone *rte_memzone_reserve_bounded(const char *name,
/**
* Free a memzone.
*
+ * Note: an IVSHMEM zone cannot be freed.
+ *
* @param mz
* A pointer to the memzone
* @return
- * -EINVAL - invalid parameter
+ * -EINVAL - invalid parameter, IVSHMEM memzone.
* 0 - success
*/
int rte_memzone_free(const struct rte_memzone *mz);
diff --git a/lib/librte_ivshmem/rte_ivshmem.c b/lib/librte_ivshmem/rte_ivshmem.c
index 9621906..8fc4b57 100644
--- a/lib/librte_ivshmem/rte_ivshmem.c
+++ b/lib/librte_ivshmem/rte_ivshmem.c
@@ -504,7 +504,22 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
config->metadata->name);
goto fail;
}
+#ifdef RTE_LIBRTE_IVSHMEM
+ struct rte_mem_config *mcfg;
+ unsigned int idx;
+ mcfg = rte_eal_get_configuration()->mem_config;
+
+ rte_rwlock_write_lock(&mcfg->mlock);
+
+ idx = ((uintptr_t)mz - (uintptr_t)mcfg->memzone);
+ idx = idx / sizeof(struct rte_memzone);
+
+ /* mark the memzone not freeable */
+ mcfg->memzone[idx].ioremap_addr = mz->phys_addr;
+
+ rte_rwlock_write_unlock(&mcfg->mlock);
+#endif
rte_spinlock_unlock(&config->sl);
return 0;
fail:
--
1.9.3
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] [PATCH 2/2] mem: fix freeing an IVSHMEM memzone
2015-08-07 15:27 ` [dpdk-dev] [PATCH 2/2] mem: fix freeing an IVSHMEM memzone Sergio Gonzalez Monroy
@ 2015-08-10 13:40 ` Thomas Monjalon
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Monjalon @ 2015-08-10 13:40 UTC (permalink / raw)
To: Sergio Gonzalez Monroy; +Cc: dev
2015-08-07 16:27, Sergio Gonzalez Monroy:
> There is no sync between host and guest to allow removal of memzones,
> and freeing them result in undefined behavior.
>
> In the guest, we identify IVSHMEM memsegs/memzones by having
> ioremap_addr != 0. In the host, nothing is done to the memzone, meaning
> ioremap_addr == 0.
>
> As a solution, mark memzones being added to IVSHMEM in the host, by
> setting ioremap_addr, then return an error whenever we try to free an
> IVSHMEM memzone.
>
> Fixes: ff909fe21f0 ("mem: introduce memzone freeing")
>
> Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Series applied, thanks
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-08-10 13:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-07 15:27 [dpdk-dev] [PATCH 1/2] mem: fix IVSHMEM Sergio Gonzalez Monroy
2015-08-07 15:27 ` [dpdk-dev] [PATCH 2/2] mem: fix freeing an IVSHMEM memzone Sergio Gonzalez Monroy
2015-08-10 13:40 ` Thomas Monjalon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).