BPF List
 help / color / mirror / Atom feed
From: Levi Zim <i@kxxt.dev>
To: Eduard Zingerman <eddyz87@gmail.com>,
	bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org
Cc: daniel@iogearbox.net, martin.lau@linux.dev, kernel-team@fb.com,
	yonghong.song@linux.dev
Subject: Re: [PATCH 0/2] bpf: calls to bpf_loop() should have an SCC and accumulate backedges
Date: Fri, 6 Mar 2026 16:20:42 +0800	[thread overview]
Message-ID: <ed857a23-bd73-4915-b080-558b5934bc8f@kxxt.dev> (raw)
In-Reply-To: <20251229-scc-for-callbacks-v1-0-ceadfe679900@gmail.com>

Hi Eduard,

On 2025-12-30 15:13, Eduard Zingerman wrote:
> This is a correctness fix for the verification of BPF programs that
> work with callback-calling functions. The problem is the same as the
> issue fixed by series [1] for iterator-based loops: some of the states
> created while processing the callback function body might have
> incomplete read or precision marks.
>
> An example of an unsafe program that is accepted without this fix can
> be found in patch #2.
>
> There is some impact on verification performance:
>
> File                             Program               Insns (A)  Insns (B)  Insns      (DIFF)
> -------------------------------  --------------------  ---------  ---------  -----------------
> pyperf600_bpf_loop.bpf.o         on_event                   4247       9985   +5738 (+135.11%)
> setget_sockopt.bpf.o             skops_sockopt              5719       7446    +1727 (+30.20%)
> setget_sockopt.bpf.o             socket_post_create         1253       1603     +350 (+27.93%)
> strobemeta_bpf_loop.bpf.o        on_event                   3424       7224   +3800 (+110.98%)
> test_tcp_custom_syncookie.bpf.o  tcp_custom_syncookie      11929      38307  +26378 (+221.12%)
> xdp_synproxy_kern.bpf.o          syncookie_tc              13986      23035    +9049 (+64.70%)
> xdp_synproxy_kern.bpf.o          syncookie_xdp             13881      21022    +7141 (+51.44%)

I see that the first patch in the series causes some impact on 
verification performance.
The patch contains "Fixes:" tag for two commits that landed in 6.17 kernel:

c9e31900b54c ("bpf: propagate read/precision marks over state graph backedges")
96c6aa4c63af ("bpf: compute SCCs in program control flow graph")

I have a BPF program [1] that is badly affected by the patch that it no 
longer loads on 6.19.5 due to
E2BIG error.

The program consists of multiple nested bpf_loop calls as follows so I 
think the impact on it is expected.

(entry point) func trace_exec_common
-> (bpf_loop) callback read_strings for reading ARGV
-> (bpf_loop) callback read_strings for reading ENVP
-> (call) read_fds
    -> (bpf_loop) callback read_fds_impl for iterating over the fdset
       -> (bpf_loop) callback read_fdset_word for reading a single word in the fdset
           -> (call) _read_fd for getting information from a single fd
               -> (call) read_send_path which reads the absolute path and mount info


After the patch, I find that I need to comment out the 
bpf_loop(BITS_PER_LONG, read_fdset_word, &subctx, 0)
statement in read_fds_impl function to make the eBPF program load.

Does it mean that after the patch, the verification performance degraded 
significantly compared to older
versions of kernel, e.g. 6.6 LTS? Or is it that older kernels are also 
impacted with the same sort of bug and
currently waiting to be fixed?

I am also exploring ways to fix my bpf program so that it could work on 
6.19.4 and later kernels.
It would be greatly appreciated if you could share some insights for 
fixing bpf programs that are badly
affected by this patch.

[1]: 
https://github.com/kxxt/tracexec/blob/main/crates/tracexec-backend-ebpf/src/bpf/tracexec_system.bpf.c

Thanks,
Levi

>
> Total progs: 4172
> Old success: 2520
> New success: 2520
> total_insns diff min:    0.00%
> total_insns diff max:  221.12%
> 0 -> value: 0
> value -> 0: 0
> total_insns abs max old: 837,487
> total_insns abs max new: 837,487
>     0 .. 5    %: 4163
>     5 .. 15   %: 2
>    25 .. 35   %: 2
>    50 .. 60   %: 1
>    60 .. 70   %: 1
>   110 .. 120  %: 1
>   135 .. 145  %: 1
>   220 .. 225  %: 1
>
> [1] https://lore.kernel.org/bpf/174968344350.3524559.14906547029551737094.git-patchwork-notify@kernel.org/
>
> ---
> Eduard Zingerman (2):
>        bpf: bpf_scc_visit instance and backedges accumulation for bpf_loop()
>        selftests/bpf: test cases for bpf_loop SCC and state graph backedges
>
>   kernel/bpf/verifier.c                     | 13 ++++--
>   tools/testing/selftests/bpf/progs/iters.c | 75 +++++++++++++++++++++++++++++++
>   2 files changed, 84 insertions(+), 4 deletions(-)
> ---
> base-commit: f14cdb1367b947d373215e36cfe9c69768dbafc9
> change-id: 20251219-scc-for-callbacks-d6d94faa2e43
>

  parent reply	other threads:[~2026-03-06  8:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-30  7:13 [PATCH 0/2] bpf: calls to bpf_loop() should have an SCC and accumulate backedges Eduard Zingerman
2025-12-30  7:13 ` [PATCH 1/2] bpf: bpf_scc_visit instance and backedges accumulation for bpf_loop() Eduard Zingerman
2025-12-30 10:20   ` Breno Leitao
2025-12-30  7:13 ` [PATCH 2/2] selftests/bpf: test cases for bpf_loop SCC and state graph backedges Eduard Zingerman
2025-12-30 17:53 ` [PATCH 0/2] bpf: calls to bpf_loop() should have an SCC and accumulate backedges Eduard Zingerman
2025-12-30 23:50 ` patchwork-bot+netdevbpf
2026-03-06  8:20 ` Levi Zim [this message]
2026-03-06  8:27   ` Eduard Zingerman
2026-03-06  9:41     ` Levi Zim
2026-03-06 15:40       ` Levi Zim
2026-03-27 19:41     ` Barret Rhoden
2026-03-27 20:10       ` Eduard Zingerman
2026-03-30 18:23         ` Barret Rhoden
2026-03-27 20:10       ` Barret Rhoden
2026-03-28  1:29         ` Alexei Starovoitov
2026-03-30 18:23           ` Barret Rhoden
2026-04-03 21:58         ` Emil Tsalapatis
2026-04-04 23:49           ` Barret Rhoden

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=ed857a23-bd73-4915-b080-558b5934bc8f@kxxt.dev \
    --to=i@kxxt.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@linux.dev \
    --cc=yonghong.song@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox