From: Eduard Zingerman <eddyz87@gmail.com>
To: Yonghong Song <yonghong.song@linux.dev>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com
Subject: Re: [PATCH bpf-next v2] bpf: Rewrite "rX <<= 32; rX >>= 32" into "wX = wX" to keep linked scalars
Date: Mon, 24 Aug 2026 11:29:37 -0700 [thread overview]
Message-ID: <6a991c643d475d77d0b5f478d760429eeb5dd554.camel@gmail.com> (raw)
In-Reply-To: <bd05af85-eedf-4749-813d-452fecd2bcbe@linux.dev>
On Sat, 2026-08-22 at 09:47 -0700, Yonghong Song wrote:
...
> > > @@ -15878,7 +15886,12 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
> > > insn->src_reg);
> > > return -EACCES;
> > > } else if (src_reg->type == SCALAR_VALUE) {
> > > - if (insn->off == 0) {
> > > + if (insn->off == 0 && insn->src_reg == insn->dst_reg &&
> > > + (dst_reg->id & BPF_ADD_CONST) &&
> > > + linked_base_fits_u32(dst_reg)) {
> > > + dst_reg->id = (dst_reg->id & ~BPF_ADD_CONST64) |
> > > + BPF_ADD_CONST32;
> > This commit consists of two parts:
> > - a special case for wA = wA assignment
> > - a rewrite for `rA <<= 32; rA >>= 32;` pair
> >
> > Could you please split it in two with separate selftest for each.
>
> Let me explain a little bit more.
>
> For these four insns
>
> 3: (bf) r2 = r1 ; R1=scalar(id=1,...) R2=scalar(id=1,...)
> 4: (07) r2 += -5 ; R2=scalar(id=1-5,smin=-5,smax=0xfffffffa)
> 5: (67) r2 <<= 32 ; R2=scalar(smax=0x7fffffff00000000,...)
> 6: (77) r2 >>= 32 ; R2=scalar(smin=0,umax=0xffffffff,...)
>
> Eventually, the above insns will be converted to
>
> 3: (bf) r2 = r1 ; R1=scalar(id=1,...) R2=scalar(id=1,...)
> 4: (07) r2 += -5 ; R2=scalar(id=1-5,smin=-5,smax=0xfffffffa)
> 5: (bc) w2 = w2 ; R2=scalar(id=1-5,smin=0,umax=0xffffffff)
> 6: (bc) w2 = w2 ; R2=scalar(id=1-5,smin=0,umax=0xffffffff)
>
> insn 5 and 6 are the ones to be changed.
>
> Here:
>
> 5: (67) r2 <<= 32 ; R2=scalar(smax=0x7fffffff00000000,...)
> 6: (77) r2 >>= 32 ; R2=scalar(smin=0,umax=0xffffffff,...)
> converted to
> 5: (bc) w2 = w2 ; R2=scalar(id=1-5,smin=0,umax=0xffffffff)
>
> This insn
> 6: (bc) w2 = w2 ; R2=scalar(id=1-5,smin=0,umax=0xffffffff)
> is not really necessary. I put it here to maintain existing control flow graph.
> Previously for insn 6, I used "goto pc+0" which will be removed later.
> But "goto pc+0" has some impact on verification as it added yet another jump.
> See bpf_is_state_visited():
>
> if (env->jmps_processed - env->prev_jmps_processed >= 2 &&
> env->insn_processed - env->prev_insn_processed >= 8)
> add_new_state = true;
>
> Here "goto pc+0" may impact for some programs. I didn't investigate this
> in detail but probably I should investigate and fix the root cause.
>
> Alternatively, we can rebuild the control flow graph by removing insn 6.
> I am just not sure whether this is worthwhile or not.
>
> > Also, could you please comment why the special case for `wA = wA` is necessary?
>
> The second wA = wA is not needed. We can remove it and rebuild the control flow
> for it, just not sure whether this is worthwhile or not. Probably yes.
I understand why you insert `wA = wA` twice, the question is about a
special case for `wA = wA` in check_alu_op(), why would you need
additional handling there specifically?
> > Is it because assign_scalar_id_before_mov() destroys the link:
> >
> > static void assign_scalar_id_before_mov(struct bpf_verifier_env *env,
> > struct bpf_reg_state *src_reg)
> > ...
> > if (src_reg->id & BPF_ADD_CONST)
> > clear_scalar_id(src_reg);
> >
> > ?
> >
> > If that's the only reason, is it possible to extend existing wA = wB
> > logic instead of adding a special case?
^^^
The above part is still relevant for the question.
prev parent reply other threads:[~2026-08-24 18:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 4:28 [PATCH bpf-next v2] bpf: Rewrite "rX <<= 32; rX >>= 32" into "wX = wX" to keep linked scalars Yonghong Song
2026-08-21 5:30 ` bot+bpf-ci
2026-08-21 17:36 ` Eduard Zingerman
2026-08-22 16:47 ` Yonghong Song
2026-08-24 18:29 ` Eduard Zingerman [this message]
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=6a991c643d475d77d0b5f478d760429eeb5dd554.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=kernel-team@fb.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.