Re: [PATCH bpf-next 1/2] bpf: support shift operations with non-const src operand

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Fri Jun 12, 2026 at 2:38 AM PDT, Tianci Cao wrote:
> Currently, the BPF verifier only allows shift operations when the shift
> amount is a known constant. This is overly restrictive for cases where
> the shift amount is bounded but not fully determined at verification time.
> For example, the following code is rejected by the verifier even though
> the shift amount is bounded to [1, 4]:
>
>     u32 shift = bpf_get_prandom_u32();
>     shift &= 3;    // shift is in range [0, 3]
>     shift += 1;    // shift is in range [1, 4]
>     r1 <<= shift;  // non-const but bounded shift amount

Rejected? I don't believe so. The verifier accepts it, but falls
back to conservative.

> Modify the shift helper functions (scalar_min_max_lsh,
> scalar32_min_max_lsh, scalar_min_max_rsh, scalar32_min_max_rsh,
> scalar_min_max_arsh, scalar32_min_max_arsh) to handle non-const
> but bounded shift amounts.
>
> Update is_safe_to_compute_dst_reg_range() to remove the src_is_const
> check for shift operations. This approach ensures the verifier
> remains sound while allowing more programs to pass verification.
>
> Also modify the comment on is_safe_to_compute_dst_reg_range.
> Shifts by more than insn bitness are legal in the BPF ISA; they are
> currently implementation-defined behaviour of the underlying architecture,
> rather than UB, and have been made legal for performance reasons.
> See: https://lore.kernel.org/bpf/20210706112502.2064236-47-sashal@kernel.org

What this is for?
Do you see such code generated by compiler in real programs?
Does it cause issues with accepting such _real_ programs ?

If not, sorry, we should not complicate the verifier for theoretical case.

pw-bot: cr