From: Paul Chaignon <paul.chaignon@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: KaFai Wan <kafai.wan@linux.dev>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>,
Srinivas Narayana <srinivas.narayana@rutgers.edu>,
Santosh Nagarakatte <santosh.nagarakatte@rutgers.edu>
Subject: Re: [PATCH v2 bpf-next 2/6] bpf: Use bpf_verifier_env buffers for reg_set_min_max
Date: Tue, 31 Mar 2026 16:56:33 +0200 [thread overview]
Message-ID: <acvgod1Tnih-EAoO@mail.gmail.com> (raw)
In-Reply-To: <d766f85ad5617da8af16a64f8903edfa3442e6d7.camel@gmail.com>
On Mon, Mar 30, 2026 at 06:51:04PM -0700, Eduard Zingerman wrote:
> On Mon, 2026-03-30 at 14:05 +0200, Paul Chaignon wrote:
> > On Mon, Mar 23, 2026 at 11:42:11AM -0700, Eduard Zingerman wrote:
> > > On Fri, 2026-03-20 at 17:49 +0100, Paul Chaignon wrote:
> >
> > [...]
> >
> > > > @@ -17196,30 +17192,23 @@ static int reg_set_min_max(struct bpf_verifier_env *env,
> > > > * variable offset from the compare (unless they were a pointer into
> > > > * the same object, but we don't bother with that).
> > > > */
> > > > - if (false_reg1->type != SCALAR_VALUE || false_reg2->type != SCALAR_VALUE)
> > > > - return 0;
> > > > -
> > > > - /* We compute branch direction for same SCALAR_VALUE registers in
> > > > - * is_scalar_branch_taken(). For unknown branch directions (e.g., BPF_JSET)
> > > > - * on the same registers, we don't need to adjust the min/max values.
> > > > - */
> > > > - if (false_reg1 == false_reg2)
> > >
> > > A side note:
> > >
> > > The above hunk was added as a part of [1] to mitigate some invariant
> > > violation errors. Surprisingly, none of the tests added in [1] fail
> > > on current master if above hunk is commented out. Probably due to
> > > recent improvements in bounds deduction. Should we remove these
> > > tests as a part of the series?
> > >
> > > [1] https://lore.kernel.org/all/20251103063108.1111764-3-kafai.wan@linux.dev/
> >
> > Nice catch! Out of those five new tests, the three "jset on same
> > register, scalar value unknown branch" never fail if you revert the
> > commit they were testing, even at the time they were added.
>
> When I get back to [1] and revert [2] I see the following test failing:
>
> verifier_bounds/jset on same register, scalar value branch taken
>
> The other two indeed pass.
I think we're saying the same thing :) My always failing tests are those
ending with "value unknown branch [1-3]", while the one ending with
"value branch taken" indeed fails as expected. I also forgot to mention
before that "jset on same register, constant value branch taken" also
never fails.
So to sum up, these never fail:
- jset on same register, constant value branch taken
- jset on same register, scalar value unknown branch 1
- jset on same register, scalar value unknown branch 2
- jset on same register, scalar value unknown branch 3
While these fail as expected:
- conditional jump on same register, branch taken
- jset on same register, scalar value branch taken
Are you suggesting to remove the first four?
>
> [1] 9f32bfec545c ("selftests/bpf: Add test for conditional jumps on same scalar register")
> [2] d43ad9da8052 ("bpf: Skip bounds adjustment for conditional jumps on same scalar register")
>
> > I believe
> > these three tests were intended to cover the above "false_reg1 ==
> > false_reg2" check and supposed to fail with an invariant violation when
> > the check is missing.
> >
> > I believe this check was never actually needed. For an invariant
> > violation to happen, we need regs_refine_cond_op to refine a register
> > based on a incorrectly-detected branch being verified. For jset, that
> > can only happen if one of the two registers is constant. In our case,
> > that would mean both registers are constant. But if both registers are
> > constant, then is_scalar_branch_taken is always able to precisely
> > deduce the outcome of the jset. Hence, we wouldn't even reach this
> > "false_reg1 == false_reg2" check.
> >
> > I think I'll remove this check in a preparatory commit, along with the
> > related selftests and an explanation why it's all not-needed. Cc'ing
> > KaFai Wan in case I missed something.
> >
> > >
> > > [...]
next prev parent reply other threads:[~2026-03-31 14:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 16:45 [PATCH v2 bpf-next 0/6] Fix invariant violations and improve branch detection Paul Chaignon
2026-03-20 16:47 ` [PATCH v2 bpf-next 1/6] bpf: Refactor reg_bounds_sanity_check Paul Chaignon
2026-03-23 8:01 ` Shung-Hsi Yu
2026-03-23 14:16 ` Mykyta Yatsenko
2026-03-24 16:56 ` Harishankar Vishwanathan
2026-03-24 18:16 ` Mykyta Yatsenko
2026-03-20 16:49 ` [PATCH v2 bpf-next 2/6] bpf: Use bpf_verifier_env buffers for reg_set_min_max Paul Chaignon
2026-03-23 8:15 ` Shung-Hsi Yu
2026-03-23 15:33 ` Mykyta Yatsenko
2026-03-23 18:42 ` Eduard Zingerman
2026-03-30 12:05 ` Paul Chaignon
2026-03-31 1:51 ` Eduard Zingerman
2026-03-31 14:56 ` Paul Chaignon [this message]
2026-03-31 14:28 ` KaFai Wan
2026-04-01 11:15 ` Paul Chaignon
2026-03-20 16:49 ` [PATCH v2 bpf-next 3/6] bpf: Exit early if reg_bounds_sync gets invalid inputs Paul Chaignon
2026-03-23 12:12 ` Shung-Hsi Yu
2026-03-24 17:46 ` Harishankar Vishwanathan
2026-03-23 18:47 ` Eduard Zingerman
2026-03-24 19:28 ` Harishankar Vishwanathan
2026-03-24 19:33 ` Eduard Zingerman
2026-04-01 12:21 ` Paul Chaignon
2026-04-01 19:36 ` Harishankar Vishwanathan
2026-04-01 20:21 ` Eduard Zingerman
2026-04-01 21:19 ` Paul Chaignon
2026-03-20 16:49 ` [PATCH v2 bpf-next 4/6] bpf: Simulate branches to prune based on range violations Paul Chaignon
2026-03-23 12:23 ` Shung-Hsi Yu
2026-03-23 16:19 ` Mykyta Yatsenko
2026-03-24 20:36 ` Harishankar Vishwanathan
2026-03-25 13:52 ` Mykyta Yatsenko
2026-03-23 19:05 ` Eduard Zingerman
2026-03-24 23:59 ` Harishankar Vishwanathan
2026-03-25 0:08 ` Eduard Zingerman
2026-03-20 16:50 ` [PATCH v2 bpf-next 5/6] selftests/bpf: Cover invariant violation cases from syzbot Paul Chaignon
2026-03-23 17:46 ` Mykyta Yatsenko
2026-03-28 16:20 ` Paul Chaignon
2026-03-28 17:31 ` Alexei Starovoitov
2026-03-20 16:50 ` [PATCH v2 bpf-next 6/6] selftests/bpf: Remove invariant violation flags Paul Chaignon
2026-03-23 18:04 ` Mykyta Yatsenko
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=acvgod1Tnih-EAoO@mail.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=kafai.wan@linux.dev \
--cc=santosh.nagarakatte@rutgers.edu \
--cc=shung-hsi.yu@suse.com \
--cc=srinivas.narayana@rutgers.edu \
/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.