From: Stephen Hemminger <stephen@networkplumber.org>
To: Marat Khalili <marat.khalili@huawei.com>
Cc: Konstantin Ananyev <konstantin.ananyev@huawei.com>,
Wathsala Vithanage <wathsala.vithanage@arm.com>, <dev@dpdk.org>
Subject: Re: [PATCH v3 02/10] bpf: introduce extensible load API
Date: Mon, 18 May 2026 10:56:58 -0700 [thread overview]
Message-ID: <20260518105658.7ca14d5b@phoenix.local> (raw)
In-Reply-To: <20260518084912.57006-3-marat.khalili@huawei.com>
On Mon, 18 May 2026 09:49:02 +0100
Marat Khalili <marat.khalili@huawei.com> wrote:
> Introduce new BPF load parameters struct rte_bpf_prm_ex that can be
> extended without breaking backward or forward compatibility. Introduce
> new function rte_bpf_load_ex consolidating in one code path loading from
> both ELF file and raw memory image, with possibility to add more options
> in the future.
>
> Some changes in code layout and sequence:
> * Both old APIs now only forwarding calls to a new single entry point.
> * There is now a centralized cleanup point for all temporary resources
> created during the load process.
> * External symbols (xsyms) are now checked for validity just after the
> load started, not after they were already used for relocation.
> * File bpf_load_elf.c now only handles opening ELF file and providing
> patched instruction array to the load process. These are left as two
> separate functions to support other ELF sources like memory image in
> the future.
> * Function stubs for the case libelf is not available are moved to
> bpf_load_elf.c to make keeping track of them easier (forgetting to
> update stubs is a common problem).
>
> Signed-off-by: Marat Khalili <marat.khalili@huawei.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> ---Review of bundle-1895: bpf load (PATCH v3 01..10/10)
Lots of AI review on this (with Claude Opus 4.7)
====================================================
Patches 01, 06, 09, and 10 had no findings and are omitted from this
review.
PATCH v3 02/10 -- bpf: introduce extensible load API
----------------------------------------------------
Errors:
* lib/bpf/bpf_load.c, rte_bpf_load() and rte_bpf_elf_load() wrappers:
These now unconditionally dereference `prm` when constructing the
compound literal passed to rte_bpf_load_ex():
return rte_bpf_load_ex(&(struct rte_bpf_prm_ex){
...
.raw.ins = prm->ins, /* NULL deref if prm == NULL */
.raw.nb_ins = prm->nb_ins,
.xsym = prm->xsym,
.nb_xsym = prm->nb_xsym,
.prog_arg = prm->prog_arg,
});
Pre-patch both functions explicitly checked `prm == NULL` and
returned NULL with rte_errno = EINVAL. The NULL check inside
load_try() does not help: NULL is dereferenced before
rte_bpf_load_ex() is even called. Add explicit
`if (prm == NULL) { rte_errno = EINVAL; return NULL; }` guards at
the top of both wrappers.
Info:
* lib/bpf/bpf_load_elf.c: the success log
"successfully creates %p(jit={.func=%p,.sz=%zu})" and the error log
in rte_bpf_elf_load() are removed silently. If intentional, mention
in the commit message.
PATCH v3 03/10 -- bpf: support up to 5 arguments
------------------------------------------------
Warnings:
* lib/bpf/bpf_exec.c, rte_bpf_exec_burst(), exec_jit_burst_ex(), and
rte_bpf_exec_burst_ex(): these return `uint32_t` but the patch
introduces `return -EINVAL` on error:
if (bpf->prm.nb_prog_arg != 1)
/* Use rte_bpf_exec_burst_ex with this program. */
return -EINVAL;
-22 reinterpreted as uint32_t is 0xFFFFFFEA, which the caller cannot
distinguish from a valid "number of successfully processed inputs"
result. The doxygen for rte_bpf_exec_burst_ex does not mention error
returns. Either change the return type, document the encoding (e.g.
any value > num indicates an error), or return 0 on these paths.
PATCH v3 04/10 -- bpf: add cBPF origin to rte_bpf_load_ex
---------------------------------------------------------
Info:
* lib/bpf/bpf_convert.c: the no-libpcap stub for rte_bpf_convert()
loses its `if (prog == NULL) return EINVAL` check when moved out of
bpf_stub.c. Previously rte_bpf_convert(NULL) returned EINVAL; now it
returns ENOTSUP. Both produce NULL so pointer-checking callers are
unaffected, but rte_errno semantics changed. Worth a mention or a
restore for symmetry with the libpcap-enabled path.
PATCH v3 05/10 -- bpf: support rte_bpf_prm_ex with port callbacks
-----------------------------------------------------------------
Errors:
* lib/bpf/rte_bpf_ethdev.h: the doxygen comments for the two new
functions are swapped:
/**
* Install callback to execute specified BPF program on given
* TX port/queue.
* ...
* @param queue
* The identifier of the TX queue on the given port
*/
__rte_experimental
int
rte_bpf_eth_rx_install(...);
/**
* Install callback to execute specified BPF program on given
* RX port/queue.
* ...
* @param queue
* The identifier of the RX queue on the given port
*/
__rte_experimental
int
rte_bpf_eth_tx_install(...);
Swap the two doc blocks.
PATCH v3 07/10 -- test/bpf: test loading cBPF directly
------------------------------------------------------
Info:
* app/test/test_bpf.c, test_bpf_filter(): the failure path previously
invoked test_bpf_dump(&fcode, prm) when load failed, useful for
diagnosing converter regressions. The refactor drops this. Consider
preserving the dump in the failure branch (or moving it into
load_cbpf_program_convert on its NULL return).
PATCH v3 08/10 -- test/bpf: test loading ELF file from memory
-------------------------------------------------------------
Errors:
* app/test/test_bpf.c, bpf_rx_test(): when rte_bpf_eth_rx_install()
fails, the loaded bpf program is leaked:
ret = rte_bpf_eth_rx_install(port, 0, bpf, flags);
if (ret != 0) {
printf(...);
return ret; /* no rte_bpf_destroy(bpf) */
}
bpf_tx_test() in the same patch correctly calls rte_bpf_destroy(bpf)
on the equivalent error path. Per the patch 05 contract, ownership
transfers to the library only on successful install. Add
`rte_bpf_destroy(bpf);` before the return.
next prev parent reply other threads:[~2026-05-18 17:57 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 17:21 [PATCH 00/10] bpf: introduce extensible load API Marat Khalili
2026-05-06 17:21 ` [PATCH 01/10] bpf: make logging prefixes more consistent Marat Khalili
2026-05-06 17:21 ` [PATCH 02/10] bpf: introduce extensible load API Marat Khalili
2026-05-06 17:22 ` [PATCH 03/10] bpf: support up to 5 arguments Marat Khalili
2026-05-06 17:22 ` [PATCH 04/10] bpf: add cBPF origin to rte_bpf_load_ex Marat Khalili
2026-05-06 17:22 ` [PATCH 05/10] bpf: support rte_bpf_prm_ex with port callbacks Marat Khalili
2026-05-06 17:22 ` [PATCH 06/10] bpf: support loading ELF files from memory Marat Khalili
2026-05-06 17:22 ` [PATCH 07/10] test/bpf: test loading cBPF directly Marat Khalili
2026-05-06 17:22 ` [PATCH 08/10] test/bpf: test loading ELF file from memory Marat Khalili
2026-05-06 17:22 ` [PATCH 09/10] doc: add release notes for new extensible BPF API Marat Khalili
2026-05-06 17:22 ` [PATCH 10/10] doc: add load API to BPF programmer's guide Marat Khalili
2026-05-09 12:36 ` [PATCH 00/10] bpf: introduce extensible load API Konstantin Ananyev
2026-05-14 9:37 ` [PATCH v2 " Marat Khalili
2026-05-14 9:37 ` [PATCH v2 01/10] bpf: make logging prefixes more consistent Marat Khalili
2026-05-14 9:37 ` [PATCH v2 02/10] bpf: introduce extensible load API Marat Khalili
2026-05-14 9:37 ` [PATCH v2 03/10] bpf: support up to 5 arguments Marat Khalili
2026-05-14 9:37 ` [PATCH v2 04/10] bpf: add cBPF origin to rte_bpf_load_ex Marat Khalili
2026-05-14 9:37 ` [PATCH v2 05/10] bpf: support rte_bpf_prm_ex with port callbacks Marat Khalili
2026-05-14 9:37 ` [PATCH v2 06/10] bpf: support loading ELF files from memory Marat Khalili
2026-05-14 9:37 ` [PATCH v2 07/10] test/bpf: test loading cBPF directly Marat Khalili
2026-05-14 9:37 ` [PATCH v2 08/10] test/bpf: test loading ELF file from memory Marat Khalili
2026-05-14 9:37 ` [PATCH v2 09/10] doc: add release notes for new extensible BPF API Marat Khalili
2026-05-14 9:37 ` [PATCH v2 10/10] doc: add load API to BPF programmer's guide Marat Khalili
2026-05-18 8:49 ` [PATCH v3 00/10] bpf: introduce extensible load API Marat Khalili
2026-05-18 8:49 ` [PATCH v3 01/10] bpf: make logging prefixes more consistent Marat Khalili
2026-05-18 8:49 ` [PATCH v3 02/10] bpf: introduce extensible load API Marat Khalili
2026-05-18 17:56 ` Stephen Hemminger [this message]
2026-05-18 8:49 ` [PATCH v3 03/10] bpf: support up to 5 arguments Marat Khalili
2026-05-18 8:49 ` [PATCH v3 04/10] bpf: add cBPF origin to rte_bpf_load_ex Marat Khalili
2026-05-18 8:49 ` [PATCH v3 05/10] bpf: support rte_bpf_prm_ex with port callbacks Marat Khalili
2026-05-18 8:49 ` [PATCH v3 06/10] bpf: support loading ELF files from memory Marat Khalili
2026-05-18 8:49 ` [PATCH v3 07/10] test/bpf: test loading cBPF directly Marat Khalili
2026-05-18 8:49 ` [PATCH v3 08/10] test/bpf: test loading ELF file from memory Marat Khalili
2026-05-18 8:49 ` [PATCH v3 09/10] doc: add release notes for new extensible BPF API Marat Khalili
2026-05-18 8:49 ` [PATCH v3 10/10] doc: add load API to BPF programmer's guide Marat Khalili
2026-05-20 12:49 ` [PATCH v4 00/11] bpf: introduce extensible load API Marat Khalili
2026-05-20 12:49 ` [PATCH v4 01/11] bpf: make logging prefixes more consistent Marat Khalili
2026-05-20 12:49 ` [PATCH v4 02/11] bpf: introduce extensible load API Marat Khalili
2026-06-10 14:46 ` Thomas Monjalon
2026-06-12 10:48 ` Marat Khalili
2026-05-20 12:49 ` [PATCH v4 03/11] bpf: support up to 5 arguments Marat Khalili
2026-05-20 12:49 ` [PATCH v4 04/11] bpf: add cBPF origin to rte_bpf_load_ex Marat Khalili
2026-05-20 12:49 ` [PATCH v4 05/11] bpf: support rte_bpf_prm_ex with port callbacks Marat Khalili
2026-05-20 12:49 ` [PATCH v4 06/11] bpf: support loading ELF files from memory Marat Khalili
2026-05-20 12:49 ` [PATCH v4 07/11] test/bpf: test loading cBPF directly Marat Khalili
2026-05-20 12:49 ` [PATCH v4 08/11] test/bpf: test loading ELF file from memory Marat Khalili
2026-05-20 12:49 ` [PATCH v4 09/11] doc: add release notes for new extensible BPF API Marat Khalili
2026-05-20 12:49 ` [PATCH v4 10/11] doc: add load API to BPF programmer's guide Marat Khalili
2026-05-20 12:49 ` [PATCH v4 11/11] test/bpf: add tests for error handling contracts Marat Khalili
2026-06-12 8:42 ` [PATCH v5 00/11] bpf: introduce extensible load API Marat Khalili
2026-06-12 8:42 ` [PATCH v5 01/11] bpf: make logging prefixes more consistent Marat Khalili
2026-06-12 8:42 ` [PATCH v5 02/11] bpf: introduce extensible load API Marat Khalili
2026-06-12 8:42 ` [PATCH v5 03/11] bpf: support up to 5 arguments Marat Khalili
2026-06-12 8:42 ` [PATCH v5 04/11] bpf: add cBPF origin to rte_bpf_load_ex Marat Khalili
2026-06-12 8:42 ` [PATCH v5 05/11] bpf: support rte_bpf_prm_ex with port callbacks Marat Khalili
2026-06-12 8:42 ` [PATCH v5 06/11] bpf: support loading ELF files from memory Marat Khalili
2026-06-12 8:42 ` [PATCH v5 07/11] test/bpf: test loading cBPF directly Marat Khalili
2026-06-12 8:42 ` [PATCH v5 08/11] test/bpf: test loading ELF file from memory Marat Khalili
2026-06-12 8:42 ` [PATCH v5 09/11] doc: add release notes for new extensible BPF API Marat Khalili
2026-06-12 8:42 ` [PATCH v5 10/11] doc: add load API to BPF programmer's guide Marat Khalili
2026-06-12 8:42 ` [PATCH v5 11/11] test/bpf: add tests for error handling contracts Marat Khalili
2026-06-12 16:06 ` [PATCH v5 00/11] bpf: introduce extensible load API Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260518105658.7ca14d5b@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.com \
--cc=marat.khalili@huawei.com \
--cc=wathsala.vithanage@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.