From: Paul Chaignon <paul.chaignon@gmail.com>
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>,
Eduard Zingerman <eddyz87@gmail.com>,
Helen Koike <koike@igalia.com>,
Yonghong Song <yonghong.song@linux.dev>
Subject: [PATCH RFC bpf-next 0/7] bpf: Fix reg_bounds' slow mode and improve verifier refinement
Date: Thu, 16 Apr 2026 15:09:39 +0200 [thread overview]
Message-ID: <cover.1776344897.git.paul.chaignon@gmail.com> (raw)
This patchset fixes several failing test cases in the slow-mode
reg_bounds selftests. It also includes an improvement to the verifier
u32->*64 refinement logic, to help better align it with reg_bounds'
refinement logic.
I'm sending as an RFC because it needs [1] to be merged first. The two
patches from [1] are included here, before my fixes.
Patch "bpf: Improve 64bits bounds refinement from u32 bounds" also
happens to address the refinement shortcomings discussed at [2]. To
demonstrate that, I included the new selftests from [2] at the end of
this series.
1: https://lore.kernel.org/all/20260415160728.657270-1-harishankar.vishwanathan@gmail.com/
2: https://lore.kernel.org/all/20260410124035.297632-1-koike@igalia.com/
Harishankar Vishwanathan (1):
bpf/verifier: Use intersection checks when simulating to detect dead
branches
Paul Chaignon (5):
selftests/bpf: Test for empty intersection of tnum and u64
selftests/bpf: Fix reg_bounds to prune on range violations
bpf: Improve 64bits bounds refinement from u32 bounds
bpf: Remove dead code from u32->*64 refinement logic
selftests/bpf: Hardcode insteresting 32->64 refinement cases
Eduard Zingerman (1):
selftests/bpf: new cases handled by 32->64 range refinements
kernel/bpf/verifier.c | 299 +++++++++++++++---
.../selftests/bpf/prog_tests/reg_bounds.c | 38 ++-
.../selftests/bpf/progs/verifier_bounds.c | 202 ++++++++++++
3 files changed, 482 insertions(+), 57 deletions(-)
--
2.43.0
next reply other threads:[~2026-04-16 13:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 13:09 Paul Chaignon [this message]
2026-04-16 13:11 ` [PATCH RFC bpf-next 1/7] bpf/verifier: Use intersection checks when simulating to detect dead branches Paul Chaignon
2026-04-16 14:03 ` bot+bpf-ci
2026-04-16 18:39 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 2/7] selftests/bpf: Test for empty intersection of tnum and u64 Paul Chaignon
2026-04-16 14:03 ` bot+bpf-ci
2026-04-16 18:53 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 3/7] selftests/bpf: Fix reg_bounds to prune on range violations Paul Chaignon
2026-04-16 19:08 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 4/7] bpf: Improve 64bits bounds refinement from u32 bounds Paul Chaignon
2026-04-16 19:33 ` sashiko-bot
2026-04-16 13:12 ` [PATCH RFC bpf-next 5/7] bpf: Remove dead code from u32->*64 refinement logic Paul Chaignon
2026-04-16 13:13 ` [PATCH RFC bpf-next 6/7] selftests/bpf: Hardcode insteresting 32->64 refinement cases Paul Chaignon
2026-04-16 13:13 ` [PATCH RFC bpf-next 7/7] selftests/bpf: new cases handled by 32->64 range refinements Paul Chaignon
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=cover.1776344897.git.paul.chaignon@gmail.com \
--to=paul.chaignon@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=harishankar.vishwanathan@gmail.com \
--cc=koike@igalia.com \
--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 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.