On FreeBSD we need to include stdint.h to get __WORDSIZE.
Type: improvement
Change-Id: I784aa0856fd8298f33016b7ccedecfa3672d5429
Signed-off-by: Tom Jones <thj@freebsd.org>
When checking for CLIB_SANITIZE_ADDR to enable specific behavior for
AddressSanitizer, we must have vppinfra/clib.h included as it is defined
there.
Type: fix
Change-Id: I9060c3c29c1289d28596c215a1d1709b2ea7c84e
Signed-off-by: Benoît Ganne <bganne@cisco.com>
Type: fix
In glibc, the __WORDSIZE macro is defined in a header included
indirectly from svm_common.h. In musl, the __WORDSIZE macro is not
indirectly included, so this patch directly includes <sys/user.h> to
ensure the __WORDSIZE macro is available.
Change-Id: If1b1fc97161b7a0b2e82351d4776c81c36a323cb
Signed-off-by: Nathan Moos <nmoos@cisco.com>
AddressSanitizer has specific requirements on memory map. In particular,
the range [0x00007fff8000, 0x10007fff7fff] is reserved for ASan use.
Type: fix
Fixes: f260eb9786
Change-Id: Ie96c4dd88b4f02d7fc5c24464572ff72cb6fd96b
Signed-off-by: Benoît Ganne <bganne@cisco.com>
Type: fix
It appears that the session layer baseva is conflicting
with DPDK. 0x2000000000 seem to be working experimentally
Configurable with :
session {
segment-baseva 0x2000000000
}
Change-Id: Ie93b9b9eb56a796877d614f78eb5801ea8e5ab31
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
* u32/u64/uword mismatches
* pointer-to-int fixes
* printf formatting issues
* issues with incorrect "ULL" and related suffixes
* structure alignment and padding issues
Change-Id: I70b989007758755fe8211c074f651150680f60b4
Signed-off-by: David Johnson <davijoh3@cisco.com>
Clients cannot know at svm region detach time if the shm backing files
have been recreated (e.g., if vpp restarts) and therefore should not try
to unlink them. Otherwise, terminating clients attached to previous
instantiations of a re-allocated region end up making the new instance
un-mappable by removing its backing file.
Change-Id: Idcd0cab776e63fd75b821bc9f0fac58217b9ccbe
Signed-off-by: Florin Coras <fcoras@cisco.com>
Mapping shared virtual memory at 0x30000000, which appears to be derived
from x86-32, turns out to be too close to the heap on arm64 systems. The
symptoms of memory corruption were random and included crashes in the
Python runtime and what appeared to be corruption of malloc's internal
mutex. Thanks to Gabriel Ganne for pointing out that disabling ASLR seemed
to mitigate the situation.
This patch maps SVM regions at an offset from the arm64 kernel constant
TASK_UNMAPPED_BASE and also assumes a 48-bit VA (for Ubuntu).
Change-Id: I642e5fe83344ab9b5c66c93e0cf1575c17251f3b
Signed-off-by: Brian Brooks <brian.brooks@arm.com>
- Teach vpp_api_test to send/receive API messages over sockets
- Add memfd-based shared memory
- Add api messages to create memfd-based shared memory segments
- vpp_api_test supports both socket and shared memory segment connections
- vpp_api_test pivot from socket to shared memory API messaging
- add socket client support to libvlibclient.so
- dead client reaper sends ping messages, container-friendly
- dead client reaper falls back to kill (<pid>, 0) live checking
if e.g. a python app goes silent for tens of seconds
- handle ping messages in python client support code
- teach show api ring about pairwise shared-memory segments
- fix ip probing of already resolved destinations (VPP-998)
We'll need this work to implement proper host-stack client isolation
Change-Id: Ic23b65f75c854d0393d9a2e9d6b122a9551be769
Signed-off-by: Dave Barach <dave@barachs.net>
Signed-off-by: Dave Wallace <dwallacelf@gmail.com>
Signed-off-by: Florin Coras <fcoras@cisco.com>
API clients would fail with an ASSERT (and core dump) whenever
the API shared memory segment could not be opened.
This returns an error value to the client's connect instead.
Change-Id: Id122a3a090b24b139c382ae09f341bde61fd2540
Signed-off-by: Ole Troan <ot@cisco.com>
This is preparation for new C API. Moving common stuff to separate
headers reduces dependency issues.
Change-Id: Ie7adb23398de72448e5eba6c1c1da4e1bc678725
Signed-off-by: Klement Sekera <ksekera@cisco.com>
