BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Levi Zim <i@kxxt.dev>,
	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, 06 Mar 2026 00:27:35 -0800	[thread overview]
Message-ID: <79ac0188db82c675e62c36c8ab036b45cef3f3f7.camel@gmail.com> (raw)
In-Reply-To: <ed857a23-bd73-4915-b080-558b5934bc8f@kxxt.dev>

On Fri, 2026-03-06 at 16:20 +0800, Levi Zim wrote:
> 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.

Hi Levi,

I'll take a detailed look tomorrow, but am curious if patch-set [1]
helps with your program? As far as I understand it is not a part of
6.19, as it was not marked as "fixes".

[1] https://lore.kernel.org/bpf/20251230-loop-stack-misc-pruning-v1-0-585cfd6cec51@gmail.com/

Thanks,
Eduard

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

  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
2026-03-06  8:27   ` Eduard Zingerman [this message]
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=79ac0188db82c675e62c36c8ab036b45cef3f3f7.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=i@kxxt.dev \
    --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