[PATCH bpf-next v2 1/8] bpf: Add UHMUL and SHMUL instructions

[bot+bpf-ci at kernel.org]

> bpf: Add UHMUL and SHMUL instructions

TL;DR: Verifier still rejects UHMUL/SHMUL (off 1/2), so the new interpreter
code is unreachable; once enabled, JITs and range tracking would silently use
low-half multiply. Should the UAPI wait for the full series?

> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index f29b0aad440c..90c30e5d790b 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -34,6 +34,12 @@
>  #define BPF_FROM_LE	BPF_TO_LE
>  #define BPF_FROM_BE	BPF_TO_BE
>
> +/* BPF_MUL off values for high-half multiplication; BPF_ALU64 only. */
> +enum bpf_mul_variant {
> +	BPF_UHMUL = 1,
> +	BPF_SHMUL = 2,
> +};
> +
>  /* jmp encodings */

Can a program that uses these new encodings be loaded at all with only this
patch applied?

check_alu_fields() in kernel/bpf/verifier.c is not touched, and it still
rejects any BPF_MUL with a non-zero off:

    case BPF_MUL:
    case BPF_DIV:
    case BPF_MOD:
        if (BPF_SRC(insn->code) == BPF_X) {
            if (insn->imm != 0 || (insn->off != 0 && insn->off != 1) ||
                (insn->off == 1 && opcode != BPF_MOD && opcode != BPF_DIV)) {
                verbose(env, "BPF_ALU uses reserved fields\n");
                return -EINVAL;
            }
        } else if (insn->src_reg != BPF_REG_0 ||
               (insn->off != 0 && insn->off != 1) ||
               (insn->off == 1 && opcode != BPF_MOD && opcode != BPF_DIV)) {

Both off == 1 (UHMUL) and off == 2 (SHMUL) fail with "BPF_ALU uses reserved
fields".

That means the UHMUL/SHMUL arms of ALU64_MUL_X and ALU64_MUL_K in
___bpf_prog_run() cannot run, and BPF_UHMUL/BPF_SHMUL describe encodings the
kernel refuses.  bpf_insn_is_hmul() in include/linux/filter.h has no callers
anywhere in the tree, and bpf_is_hmul_variant() is only called by it, so both
are currently dead code.

The commit message mentions interpreter support, but does not say that the
verifier change is left for later.

When the verifier is relaxed, the JITs and the range tracking will also need
attention.  The JITs ignore insn->off for BPF_MUL today; for example
arch/x86/net/bpf_jit_comp.c emits a plain imul for
"case BPF_ALU64 | BPF_MUL | BPF_K/X".  adjust_scalar_min_max_vals() models
BPF_MUL as a low-half multiply.  Without changes there, JITed programs would
silently compute the low half and the verifier's bounds would not match the
real result.

Should the UAPI constants and the divmul64v2 group wait until verifier, JIT
and selftest support land in the same series, or should the unused
bpf_insn_is_hmul() be dropped from this patch?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/39552088777