[dpdk-dev] [PATCH] ivshmem: document a potential segmentation fault in rte_ring

[dpdk-dev] [PATCH] ivshmem: document a potential segmentation fault in rte_ring

[Anatoly Burakov]

Commit 4768c475 added a pointer to the memzone in rte_ring. However,
all memzones are residing in local mem_config, therefore accessing
the memzone pointer inside the guest in an IVSHMEM-shared rte_ring
will cause segmentation fault. This issue is unlikely to ever get
fixed, as this would require lots of changes for very little benefit,
therefore we're documenting this limitation instead.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
 doc/guides/prog_guide/ivshmem_lib.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/guides/prog_guide/ivshmem_lib.rst b/doc/guides/prog_guide/ivshmem_lib.rst
index 9401ccf..b8a32e4 100644
--- a/doc/guides/prog_guide/ivshmem_lib.rst
+++ b/doc/guides/prog_guide/ivshmem_lib.rst
@@ -79,6 +79,8 @@ The following is a simple guide to using the IVSHMEM Library API:
     Only data structures fully residing in DPDK hugepage memory work correctly.
     Supported data structures created by malloc(), mmap()
     or otherwise using non-DPDK memory cause undefined behavior and even a segmentation fault.
+    Specifically, because the memzone field in an rte_ring refers to a memzone structure residing in local memory,
+    accessing the memzone field in a shared rte_ring will cause an immediate segmentation fault.
 
 IVSHMEM Environment Configuration
 ---------------------------------
-- 
2.5.0

Re: [dpdk-dev] [PATCH] ivshmem: document a potential segmentation fault in rte_ring

[Thomas Monjalon]

2016-06-01 15:51, Anatoly Burakov:
> Commit 4768c475 added a pointer to the memzone in rte_ring. However,
> all memzones are residing in local mem_config, therefore accessing
> the memzone pointer inside the guest in an IVSHMEM-shared rte_ring
> will cause segmentation fault. This issue is unlikely to ever get
> fixed, as this would require lots of changes for very little benefit,
> therefore we're documenting this limitation instead.
> 
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>

Applied, thanks