From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Eduard Zingerman" <eddyz87@gmail.com>, <bpf@vger.kernel.org>,
<andrii@kernel.org>
Cc: <daniel@iogearbox.net>, <kernel-team@fb.com>,
<yonghong.song@linux.dev>, <memxor@gmail.com>
Subject: Re: [PATCH bpf-next v2 1/2] bpf: reject pointer operands for 32-bit recurrences/latches
Date: Wed, 21 Oct 2026 22:22:13 +0000 [thread overview]
Message-ID: <DMAV87WUFF7M.1PU3M3CCZJDQJ@gmail.com> (raw)
In-Reply-To: <20261021185609.607075-1-eddyz87@gmail.com>
On Wed, Oct 21, 2026 at 11:56 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
> Fixes: df4761bd441c ("bpf: Support 32-bit linear scalar evolution")
sorry, few commits were dropped from bpf-next.
It's 32e962577d2d now.
> + /* 32-bit ALU operations on pointers convert them to scalars */
> + if (coefs.zext32 && reg->type != SCALAR_VALUE)
> + goto cant_widen;
le64 does the same without zext32.
r7 = map_value, r1 = 0
l: r7 = le64 r7
if r7 < 100 goto out
if r7 > 1000 goto out
r7 += 8
r1 += 1
if r1 != 4 goto l
On little endian transfer() treats le64 as a nop, so r7 at the header
is (linear r7 8), while check_alu_op() makes it an unknown scalar.
At the backedge r7 is a scalar 108..1008 and bpf_clamp_scev_regs()
intersects it with 0..24, the offsets of map_value at the loop entry:
verifier bug: scev clamp produced empty range for r7
Should bpf_clamp_scev_regs() skip the reg when
entry_reg->type != reg->type
?
next prev parent reply other threads:[~2026-10-21 22:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 18:56 [PATCH bpf-next v2 1/2] bpf: reject pointer operands for 32-bit recurrences/latches Eduard Zingerman
2026-10-21 18:56 ` [PATCH bpf-next v2 2/2] selftests/bpf: " Eduard Zingerman
2026-10-21 18:57 ` [PATCH bpf-next v2 1/2] bpf: reject " Eduard Zingerman
2026-10-21 22:22 ` Alexei Starovoitov [this message]
2026-10-21 22:50 ` Eduard Zingerman
2026-10-23 1:04 ` Eduard Zingerman
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=DMAV87WUFF7M.1PU3M3CCZJDQJ@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
--cc=memxor@gmail.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.