> bpf: Add log support for tracing link_create TL;DR: Logging is incomplete: the freplace max_ctx_offset check in bpf_tracing_prog_attach() still returns -EINVAL with an empty log, and the saved_dst type mismatch may too. No functional regression. > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c [ ... ] > @@ -3843,6 +3849,7 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog, > */ > if (prog->type == BPF_PROG_TYPE_EXT && > prog->aux->kprobe_write_ctx != tgt_prog->aux->kprobe_write_ctx) { > + bpf_log(log, "Invalid kprobe_write_ctx.\n"); > err = -EINVAL; > goto out_unlock; > } The check right after this one still returns -EINVAL without writing anything to the log: if (prog->type == BPF_PROG_TYPE_EXT && (tgt_prog->type == BPF_PROG_TYPE_RAW_TRACEPOINT || tgt_prog->type == BPF_PROG_TYPE_TRACEPOINT || tgt_prog->type == BPF_PROG_TYPE_SYSCALL) && prog->aux->max_ctx_offset > tgt_prog->aux->max_ctx_offset) { err = -EINVAL; goto out_unlock; } An freplace program whose max_ctx_offset is larger than that of a RAW_TRACEPOINT, TRACEPOINT or SYSCALL target will get -EINVAL from link_create with an empty log and log_true_size of 0. That is the same kind of invalid freplace target as the kprobe_write_ctx mismatch above, which now logs. This isn't a functional regression, but was this check missed? Would something like this cover it? bpf_log(log, "Extension accesses more ctx than its target.\n"); Also, bpf_check_attach_target() still returns a bare -EINVAL for the saved_dst_prog_type / saved_dst_attach_type mismatch, which is the "freplace attachment to a new target" case the commit message mentions. That code is in verifier.c, so it is outside this patch, but is it intended to be left without a message? --- 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/42633880300