On Tue, Feb 25, 2025 at 5:50 AM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
>
>
>
> 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/
This is orthogonal.
"Some future feature may use it" is not an excuse to add code now.
Especially uapi.
