Re: [PATCHv5 06/13] libbpf: Change has_nop_combo to work on top of nop10

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch breaks USDT optimization selftests and functionally fails to enable the optimization because the kernel does not support optimizing 10-byte NOPs.
--

commit 7b26e4395329f0d2e4ebce57947c8615c8552ea2
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Change has_nop_combo to work on top of nop10

This commit modifies libbpf's USDT parsing to check for an 11-byte NOP
combination (nop + nop10) instead of the previous 6-byte combination
(nop + nop5). The intent is to leverage faster uprobe handling.

> diff --git a/tools/lib/bpf/usdt.c b/tools/lib/bpf/usdt.c
> index 57fb82bb81b58..d2ecd3daab961 100644
> --- a/tools/lib/bpf/usdt.c
> +++ b/tools/lib/bpf/usdt.c
[ ... ]
> @@ -604,14 +604,14 @@ static int parse_usdt_spec(struct usdt_spec *spec, const struct usdt_note *note,
>  #if defined(__x86_64__)
>  static bool has_nop_combo(int fd, long off)
>  {
> -	unsigned char nop_combo[6] = {
> -		0x90, 0x0f, 0x1f, 0x44, 0x00, 0x00 /* nop,nop5 */
> +	unsigned char nop_combo[11] = {
> +		0x90, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00,
>  	};
> -	unsigned char buf[6];
> +	unsigned char buf[11];
>  
> -	if (pread(fd, buf, 6, off) != 6)
> +	if (pread(fd, buf, 11, off) != 11)
>  		return false;
> -	return memcmp(buf, nop_combo, 6) == 0;
> +	return memcmp(buf, nop_combo, 11) == 0;
>  }

[Severity: High]
Will this modification break the USDT optimization selftests and prevent uprobes
from being optimized?

The BPF selftests still emit a 6-byte NOP combo:

tools/testing/selftests/bpf/usdt.h:
    #define USDT_NOP                       .byte 0x90, 0x0f, 0x1f, 0x44, 0x00, 0x0 /* nop, nop5 */

Because libbpf now strictly requires an 11-byte sequence, it skips the
optimization for existing tests. This causes subtest_optimized_attach() in
tools/testing/selftests/bpf/prog_tests/usdt.c to fail its assertion:

    ASSERT_EQ(*(addr_2 + 1), 0xe8, "call");

The assertion fails because the uprobe falls back to an unoptimized 1-byte INT3
(0xcc) instead of the optimized 5-byte call (0xe8) at addr_2 + 1.

Furthermore, if user-space were to emit the 10-byte NOP, is the kernel currently
capable of optimizing it? Looking at arch/x86/kernel/uprobes.c:

arch/x86/kernel/uprobes.c:can_optimize() {
    ...
    if (!insn->x86_64 || insn->length != 5)
        return false;
    ...
}

Because the kernel strictly requires the instruction length to be exactly 5 bytes,
a 10-byte NOP will be rejected for optimization. The kernel will fall back to an
INT3 uprobe, meaning the intended uprobe syscall optimization is not achieved.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701111337.53943-7-jolsa@kernel.org?part=1