Re: [PATCH bpf-next v2] libbpf: Add support for dynamic program attach target

["Toke Høiland-Jørgensen" <toke@redhat.com>]

"Eelco Chaudron" <echaudro@redhat.com> writes:

> On 13 Feb 2020, at 16:32, Toke Høiland-Jørgensen wrote:
>
>> Eelco Chaudron <echaudro@redhat.com> writes:
>>
>>> Currently when you want to attach a trace program to a bpf program
>>> the section name needs to match the tracepoint/function semantics.
>>>
>>> However the addition of the bpf_program__set_attach_target() API
>>> allows you to specify the tracepoint/function dynamically.
>>>
>>> The call flow would look something like this:
>>>
>>>   xdp_fd = bpf_prog_get_fd_by_id(id);
>>>   trace_obj = bpf_object__open_file("func.o", NULL);
>>>   prog = bpf_object__find_program_by_title(trace_obj,
>>>                                            "fentry/myfunc");
>>>   bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY);
>>>   bpf_program__set_attach_target(prog, xdp_fd,
>>>                                  "xdpfilt_blk_all");
>>>   bpf_object__load(trace_obj)
>>>
>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>
>> Hmm, one question about the attach_prog_fd usage:
>>
>>> +int bpf_program__set_attach_target(struct bpf_program *prog,
>>> +				   int attach_prog_fd,
>>> +				   const char *attach_func_name)
>>> +{
>>> +	int btf_id;
>>> +
>>> +	if (!prog || attach_prog_fd < 0 || !attach_func_name)
>>> +		return -EINVAL;
>>> +
>>> +	if (attach_prog_fd)
>>> +		btf_id = libbpf_find_prog_btf_id(attach_func_name,
>>> +						 attach_prog_fd);
>>> +	else
>>> +		btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux,
>>> +					       attach_func_name,
>>> +					       prog->expected_attach_type);
>>
>> This implies that no one would end up using fd 0 as a legitimate prog
>> fd. This already seems to be the case for the existing code, but is 
>> that
>> really a safe assumption? Couldn't a caller that closes fd 0 (for
>> instance while forking) end up having it reused? Seems like this could
>> result in weird hard-to-debug bugs?
>
>
> Yes, in theory, this can happen but it has nothing to do with this 
> specific patch. The existing code already assumes that attach_prog_fd == 
> 0 means attach to a kernel function :(

Yup, I do realise you're just sticking to the existing behaviour. Seems
even the kernel does that check for fd != 0, so I guess that's ABI now.
Still not sure I believe this will not trip anyone up, though... :/

-Toke