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
