Re: [PATCH bpf 1/2] libbpf: Fix usdt attach failure when nop10 crosses page boundary
Jiayuan Chen <[email protected]>
| Newsgroups | org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <[email protected]> |
On 8/24/26 6:03 PM, [email protected] wrote: >> Fixes: 41a5c7df4466 ("libbpf: Add support to detect nop,nop5 instructions combo for usdt probe") >> Signed-off-by: Jiayuan Chen <[email protected]> > Does the Fixes tag point at the right commit? The -ENOTSUPP attach > failure could not happen at 41a5c7df4466. > > At 41a5c7df4466 the uprobe was shifted onto a nop5 (0f 1f 44 00 00), and > arch_uprobe_analyze_insn() ran uprobe_init_insn() unconditionally: > > ret = uprobe_init_insn(auprobe, &insn, is_64bit_mm(mm)); > if (ret) > return ret; > if (can_optimize(&insn, addr)) > set_bit(ARCH_UPROBE_FLAG_CAN_OPTIMIZE, &auprobe->flags); > > uprobe_init_insn() accepts nop5: is_prefix_bad() finds no prefix, and > test_bit(OPCODE1 == 0x0f, good_insns_64) is set. So a nop5 that crossed > a page boundary simply produced a normal, working int3 uprobe. The attach > succeeded. > > The failure was introduced by the nop10 switch: > > 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10") > made can_optimize() failure fall through to uprobe_init_insn(), and the > nop10's 0x2e byte is a CS prefix that is_prefix_bad() rejects: > > if (can_optimize(&insn, addr)) { > set_bit(ARCH_UPROBE_FLAG_CAN_OPTIMIZE, &auprobe->flags); > } else { > ret = uprobe_init_insn(auprobe, &insn); > if (ret) > return ret; > } > > ee2862439e5c ("libbpf: Change has_nop_combo to work on top of nop10") > made libbpf shift the uprobe onto that nop10. > > Should the tag be: > > Fixes: ee2862439e5c ("libbpf: Change has_nop_combo to work on top of nop10") ee2862439e5c is correct. Waiting for more feedback. > This also matters for backport scope: a tree that has 41a5c7df4466 but > not ee2862439e5c still matches the 6-byte nop,nop5 pattern, where the > new hardcoded +10 in nop10_within_page() would be over-strict by 5 bytes > while the bug being fixed does not exist there. > > > > --- > 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/32712703327