On 2025/2/25 03:41, Alexei Starovoitov wrote:
> On Mon, Feb 24, 2025 at 7:34 AM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
>>
>> @@ -3539,7 +3540,7 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
>> */
>> struct bpf_attach_target_info tgt_info = {};
>>
>> - err = bpf_check_attach_target(NULL, prog, tgt_prog, btf_id,
>> + err = bpf_check_attach_target(log, prog, tgt_prog, btf_id,
>> &tgt_info);
>
> I still don't like this uapi addition.
>
> It only helps a rare corner case of freplace usage:
> /* If there is no saved target, or the specified target is
> * different from the destination specified at load time, we
> * need a new trampoline and a check for compatibility
> */
>
> If it was useful in more than one case we could consider it,
> but uapi addition for a single rare use, is imo wrong trade off.
>
Got it.
I'm planning to implement a restrict version of
"bpf: make tracing program support multi-link"[0]. With log buffer, it
will be helpful to report the reason for declining attaching, especially
to report the tracee info that causes the attachment failure.
[0]
https://lore.kernel.org/bpf/20240311093526.1010158-1-dongmenglong.8@xxxxxxxxxxxxx/
Thanks,
Leon
