> 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")
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
