bpf: fix free function mismatch if convert fails

If conversion of cBF to eBPF fails then an object allocated with
rte_malloc() would be passed to free().

[908/3201] Compiling C object lib/librte_bp

bpf: fix free function mismatch if convert fails

If conversion of cBF to eBPF fails then an object allocated with
rte_malloc() would be passed to free().

[908/3201] Compiling C object lib/librte_bpf.a.p/bpf_bpf_convert.c.o
../lib/bpf/bpf_convert.c: In function ‘rte_bpf_convert’:
../lib/bpf/bpf_convert.c:559:17:
warning: ‘free’ called on pointer returned from a mismatched
allocation function [-Wmismatched-dealloc]
559 | free(prm);
| ^~~~~~~~~
../lib/bpf/bpf_convert.c:545:15: note: returned from ‘rte_zmalloc’
545 | prm = rte_zmalloc("bpf_filter",
| ^~~~~~~~~~~~~~~~~~~~~~~~~
546 | sizeof(*prm) + ebpf_len * sizeof(*ebpf), 0);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fixes: 2eccf6afbea9 ("bpf: add function to convert classic BPF to DPDK BPF")
Cc: stable@dpdk.org

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Wathsala Vithanage <wathsala.vithanage@arm.com>

show more ...

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

Dealing with C++ should delegate to the individual include file level,
rather than being imposed by the user of that file. For example,
forcing C linkage prevents __Generic macros being replaced with
overloaded static inline functions in C++ translation units.

Eliminate 'extern "C"' from files which do not declare any symbols
(e.g., only macros or struct types).

On the other hand, the headers check is too naive in assuming that all
headers must contain a 'extern "C"'. Such a check was added in commit
1ee492bdc4ff ("buildtools/chkincs: check missing C++ guards").
Since this current change results in many headers not containing such
a token, remove the check for 'extern "C"' until we have a better
implementation.

Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>

show more ...

version: 24.11-rc0

Start a new release cycle with empty release notes.

The ABI version becomes 25.0.
The map files are updated to the new ABI major number (25).
The ABI exceptions are dropped and C

version: 24.11-rc0

Start a new release cycle with empty release notes.

The ABI version becomes 25.0.
The map files are updated to the new ABI major number (25).
The ABI exceptions are dropped and CI ABI checks are disabled because
compatibility is not preserved.

Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

bpf: fix load hangs with six IPv6 addresses

As described in https://bugs.dpdk.org/show_bug.cgi?id=1465, converting
from following cBPF filter:
"host 1::1 or host 1::1 or host 1::1 or host 1::1 or
h

bpf: fix load hangs with six IPv6 addresses

As described in https://bugs.dpdk.org/show_bug.cgi?id=1465, converting
from following cBPF filter:
"host 1::1 or host 1::1 or host 1::1 or host 1::1 or
host 1::1 or host 1::1"
takes too long for BPF verifier to complete (up to 25 seconds).

Looking at it, I didn't find any actual functional bug.

In fact, it does what is expected: go through each possible path of
BPF program and evaluate register/stack state for each instruction.
The problem is that, for program with a lot of conditional branches,
number of possible paths starts to grow exponentially and such walk
becomes very excessive.

So to minimize number of evaluations, this patch implements heuristic
similar to what Linux kernel does: state pruning.
If from given instruction for given program state, we explore all possible
paths and for each of them reach bpf_exit() without any complaints and a
valid R0 value, then for that instruction this program state can be
marked as 'safe'.
When we later arrive at the same instruction with a state equivalent to
an earlier instruction 'safe' state, we can prune the search.

For now, only states for JCC targets are saved/examined.

Plus add few extra logging for DEBUG level.

Bugzilla ID: 1465
Fixes: 8021917293d0 ("bpf: add extra validation for input BPF program")
Cc: stable@dpdk.org

Reported-by: Isaac Boukris <iboukris@gmail.com>
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

bpf: fix MOV instruction evaluation

Verifier might left some register-state values uninitialized while
evaluating MOV instructions.
Add explicit initialization.

Fixes: 8021917293d0 ("bpf: add extra

bpf: fix MOV instruction evaluation

Verifier might left some register-state values uninitialized while
evaluating MOV instructions.
Add explicit initialization.

Fixes: 8021917293d0 ("bpf: add extra validation for input BPF program")
Cc: stable@dpdk.org

Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>

show more ...

bpf: disable on 32-bit x86

As per Intel, this is not supported, and the librte-bpf test fails on
32bit x86 kernels, so disable the library and the pmd.

Cc: stable@dpdk.org

Signed-off-by: Luca Bocc

bpf: disable on 32-bit x86

As per Intel, this is not supported, and the librte-bpf test fails on
32bit x86 kernels, so disable the library and the pmd.

Cc: stable@dpdk.org

Signed-off-by: Luca Boccassi <bluca@debian.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

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 ...

lib: use log helper with prefix

Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
which allows a prefix and arguments to be inserted into the log line
without the need to use the #

lib: use log helper with prefix

Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
which allows a prefix and arguments to be inserted into the log line
without the need to use the ## args variadic argument pack extension.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>

show more ...