From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F03B946635; Sat, 26 Apr 2025 00:47:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8A73F4026A; Sat, 26 Apr 2025 00:47:30 +0200 (CEST) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 6A7534025E for ; Sat, 26 Apr 2025 00:47:29 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id 4DA0046637; Sat, 26 Apr 2025 00:47:29 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/core Bug 1700] BPF callback wait is not MP safe Date: Fri, 25 Apr 2025 22:47:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: core X-Bugzilla-Version: 25.03 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: stephen@networkplumber.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17456212490.aC61FB9c2.1307451 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --17456212490.aC61FB9c2.1307451 Date: Sat, 26 Apr 2025 00:47:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1700 Bug ID: 1700 Summary: BPF callback wait is not MP safe Product: DPDK Version: 25.03 Hardware: All OS: All Status: UNCONFIRMED Severity: minor Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: stephen@networkplumber.org Target Milestone: --- The mechanism implemented in bpf_pkt.c is like an open coded version of seqlock. There is an inherit race because: If the CPU running the callback doesn't reach the before the count is executed, it can rance with the CPU doing destroy. CPU 1: CPU 2: bpf_eth_unload() bc =3D bpf_eth_cbh_find() bpf_rx_callback_vm (or bpf_rx_callback_jit) rte_eth_remove_rx_callback() bpf_eth_cbi_unload(bc) bpf_eth_cbi_wait(bc) at this point bc->inuse =3D=3D 0 because call back not started but is going to be used by CPU 2. And calling rte_bpf_destroy will lead to use after free. There is no good way to fix this without using RCU. Also, the code should be consistently using C11 atomic not barriers. Not sure if anyone ever uses this code anyway! --=20 You are receiving this mail because: You are the assignee for the bug.= --17456212490.aC61FB9c2.1307451 Date: Sat, 26 Apr 2025 00:47:29 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All

Bug ID	1700
Summary	BPF callback wait is not MP safe
Product	DPDK
Version	25.03
Hardware	All
OS	All
Status	UNCONFIRMED
Severity	minor
Priority	Normal
Component	core
Assignee	dev@dpdk.org
Reporter	stephen@networkplumber.org
Target Milestone	---

The mechanism implemented in bpf_p=
kt.c is like an open coded version of
seqlock.
There is an inherit race because:

If the CPU running the callback doesn't reach the before the count
is executed, it can rance with the CPU doing destroy.

CPU 1:                                CPU 2:
bpf_eth_unload()
    bc =3D bpf_eth_cbh_find()
                                      bpf_rx_callback_vm (or
bpf_rx_callback_jit)
    rte_eth_remove_rx_callback()
    bpf_eth_cbi_unload(bc)
        bpf_eth_cbi_wait(bc)

at this point bc->inuse =3D=3D 0 because call back not started
but is going to be used by CPU 2. And calling rte_bpf_destroy
will lead to use after free.

There is no good way to fix this without using RCU.

Also, the code should be consistently using C11 atomic not barriers.
Not sure if anyone ever uses this code anyway!

You are receiving this mail because:

You are the assignee for the bug.

=20=20=20=20=20=20=20=20=20=20

= --17456212490.aC61FB9c2.1307451--