|
Revision tags: v24.07-rc2, v24.07-rc1, v24.03, v24.03-rc4, v24.03-rc3, v24.03-rc2 |
|
| #
c6552d9a |
| 04-Mar-2024 |
Tyler Retzlaff <roretzla@linux.microsoft.com> |
lib: move alignment attribute on types for MSVC
The current location used for __rte_aligned(a) for alignment of types is not compatible with MSVC. There is only a single location accepted by both to
lib: move alignment attribute on types for MSVC
The current location used for __rte_aligned(a) for alignment of types is not compatible with MSVC. There is only a single location accepted by both toolchains.
The standard offers no alignment facility that compatibly interoperates with C and C++ but it may be achieved by relocating the placement of __rte_aligned(a) to the aforementioned location accepted by all currently supported toolchains.
To allow alignment for both compilers, do the following:
* Expand __rte_aligned(a) to __declspec(align(a)) when building with MSVC.
* Move __rte_aligned from the end of {struct,union} definitions to be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired alignment to be imparted on the type regardless of the toolchain being used for all of GCC, LLVM, MSVC compilers building both C and C++.
Note: this move has an additional benefit as Doxygen is not confused anymore like for the rte_event_vector struct definition.
Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com> Acked-by: Morten Brørup <mb@smartsharesystems.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com> Acked-by: Chengwen Feng <fengchengwen@huawei.com> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: David Marchand <david.marchand@redhat.com>
show more ...
|
|
Revision tags: v24.03-rc1, v23.11, v23.11-rc4, v23.11-rc3, v23.11-rc2, v23.11-rc1, v23.07, v23.07-rc4, v23.07-rc3, v23.07-rc2, v23.07-rc1, v23.03, v23.03-rc4, v23.03-rc3, v23.03-rc2, v23.03-rc1, v22.11, v22.11-rc4, v22.11-rc3, v22.11-rc2, v22.11-rc1, v22.07, v22.07-rc4, v22.07-rc3, v22.07-rc2, v22.07-rc1 |
|
| #
48ff13ef |
| 05-May-2022 |
David Marchand <david.marchand@redhat.com> |
test/mem: disable ASan when accessing unallocated memory
As described in bugzilla, ASan reports accesses to all memory segment as invalid, since those parts have not been allocated with rte_malloc.
test/mem: disable ASan when accessing unallocated memory
As described in bugzilla, ASan reports accesses to all memory segment as invalid, since those parts have not been allocated with rte_malloc. Move __rte_no_asan to rte_common.h and disable ASan on a part of the test.
Bugzilla ID: 880 Fixes: 6cc51b1293ce ("mem: instrument allocator for ASan") Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
| #
4d8bdd8b |
| 04-May-2022 |
Anatoly Burakov <anatoly.burakov@intel.com> |
malloc: fix ASan handling for unmapped memory
Currently, when we free previously allocated memory, we mark the area as "freed" for ASan purposes (flag 0xfd). However, sometimes, freeing a malloc ele
malloc: fix ASan handling for unmapped memory
Currently, when we free previously allocated memory, we mark the area as "freed" for ASan purposes (flag 0xfd). However, sometimes, freeing a malloc element will cause pages to be unmapped from memory and re-backed with anonymous memory again. This may cause ASan's "use-after-free" error down the line, because the allocator will try to write into memory areas recently marked as "freed".
To fix this, we need to mark the unmapped memory area as "available", and fixup surrounding malloc element header/trailers to enable later malloc routines to safely write into new malloc elements' headers or trailers.
Bugzilla ID: 994 Fixes: 6cc51b1293ce ("mem: instrument allocator for ASan") Cc: stable@dpdk.org
Reported-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
|
Revision tags: v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2, v22.03-rc1 |
|
| #
2edd037c |
| 03-Feb-2022 |
Dmitry Kozlyuk <dkozlyuk@nvidia.com> |
mem: add dirty malloc element support
EAL malloc layer assumed all free elements content is filled with zeros ("clean"), as opposed to uninitialized ("dirty"). This assumption was ensured in two way
mem: add dirty malloc element support
EAL malloc layer assumed all free elements content is filled with zeros ("clean"), as opposed to uninitialized ("dirty"). This assumption was ensured in two ways: 1. EAL memalloc layer always returned clean memory. 2. Freed memory was cleared before returning into the heap.
Clearing the memory can be as slow as around 14 GiB/s. To save doing so, memalloc layer is allowed to return dirty memory. Such segments being marked with RTE_MEMSEG_FLAG_DIRTY. The allocator tracks elements that contain dirty memory using the new flag in the element header. When clean memory is requested via rte_zmalloc*() and the suitable element is dirty, it is cleared on allocation. When memory is deallocated, the freed element is joined with adjacent free elements, and the dirty flag is updated:
a) If the joint element contains dirty parts, it is dirty:
dirty + freed + dirty = dirty => no need to clean freed + dirty = dirty the freed memory
Dirty parts may be large (e.g. initial allocation), so clearing them could create unpredictable slowdown.
b) If the only dirty part of the joint element is the freed memory, the joint element can be made clean:
clean + freed + clean = clean => freed memory clean + freed = clean must be cleared freed + clean = clean freed = clean
This logic naturally reproduces the old behavior and always applies in modes when EAL memalloc layer returns only clean segments.
As a result, memory is either cleared on free, as before, or it will be cleared on allocation if need be, but never twice.
Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
|
Revision tags: v21.11, v21.11-rc4, v21.11-rc3 |
|
| #
f2a66612 |
| 15-Nov-2021 |
David Christensen <drc@linux.vnet.ibm.com> |
eal/ppc: support ASan
Add support for Address Sanitizer (ASan) for PPC/POWER architecture.
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com> Reviewed-by: David Marchand <david.marchand@redh
eal/ppc: support ASan
Add support for Address Sanitizer (ASan) for PPC/POWER architecture.
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com> Reviewed-by: David Marchand <david.marchand@redhat.com>
show more ...
|
| #
001d402c |
| 09-Nov-2021 |
Volodymyr Fialko <vfialko@marvell.com> |
eal/arm64: support ASan
This patch defines ASAN_SHADOW_OFFSET for arm64 according to the ASan documentation. This offset should cover all arm64 VMAs supported by ASan.
Signed-off-by: Volodymyr Fial
eal/arm64: support ASan
This patch defines ASAN_SHADOW_OFFSET for arm64 according to the ASan documentation. This offset should cover all arm64 VMAs supported by ASan.
Signed-off-by: Volodymyr Fialko <vfialko@marvell.com> Reviewed-by: David Marchand <david.marchand@redhat.com> Acked-by: Jerin Jacob <jerinj@marvell.com> Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
show more ...
|
|
Revision tags: v21.11-rc2, v21.11-rc1 |
|
| #
6cc51b12 |
| 20-Oct-2021 |
Zhihong Peng <zhihongx.peng@intel.com> |
mem: instrument allocator for ASan
This patch adds necessary hooks in the memory allocator for ASan.
This feature is currently available in DPDK only on Linux x86_64. If other OS/architectures want
mem: instrument allocator for ASan
This patch adds necessary hooks in the memory allocator for ASan.
This feature is currently available in DPDK only on Linux x86_64. If other OS/architectures want to support it, ASAN_SHADOW_OFFSET must be defined and RTE_MALLOC_ASAN must be set accordingly in meson.
Signed-off-by: Xueqin Lin <xueqin.lin@intel.com> Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
|
Revision tags: v21.08, v21.08-rc4, v21.08-rc3, v21.08-rc2, v21.08-rc1, v21.05, v21.05-rc4, v21.05-rc3, v21.05-rc2, v21.05-rc1 |
|
| #
99a2dd95 |
| 20-Apr-2021 |
Bruce Richardson <bruce.richardson@intel.com> |
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also m
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also makes it awkward to add features referring to individual libraries in the build - should the lib names be specified with or without the prefix. Therefore, we can just remove the library prefix and use the library's unique name as the directory name, i.e. 'eal' rather than 'librte_eal'
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
show more ...
|