Re: [PATCH bpf v3 4/7] bpf: Restrict CO-RE poisoning to relocatable instructions

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-09-14 at 14:15 +0000, bot+bpf-ci@kernel.org wrote:

...

> > @@ -1066,6 +1055,8 @@ int bpf_core_patch_insn(const char *prog_name, struct bpf_insn *insn,
> >  	case BPF_ALU64:
> >  		if (BPF_SRC(insn->code) != BPF_K)
> >  			return -EINVAL;
> > +		if (res->poison)
> > +			goto poison;
> 
> Moving the poison handling after the class/operand-form checks makes the
> silent return -EINVAL reachable for unresolved relocations. Would adding a
> pr_warn() on this path help with debugging?
> 
> Before this change, relocations with res->poison set jumped to the poison
> label at the top of the function and always returned 0 without reaching
> the BPF_SRC check. Now an unresolved relocation targeting a register-source
> ALU or ALU64 instruction (BPF_MOV32_REG, BPF_MOV64_REG, or
> BPF_ALU|BPF_END|BPF_TO_BE which encodes BPF_SRC == BPF_X) fails program
> load with -EINVAL and nothing in the verifier or libbpf log explaining why.

Ok, this might be a legit nit.
Add a goto default switch branch instead of `return -EINVAL;`
in the BPF_ALU64 case?

...