linux-kernel - Re: [PATCH v2 bpf-next 2/4] libbpf: Add helpers to extract perf fd from bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzYsfpkze7ohmusztW3Hc8FUsu5jHk2kpmffmMkejpxq6g@mail.gmail.com>
Date:   Mon, 12 Aug 2019 09:02:33 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Daniel Xu <dxu@...uu.xyz>
Cc:     Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>, peterz@...raded.org,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexei Starovoitov <ast@...com>,
        alexander.shishkin@...ux.intel.com, Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 bpf-next 2/4] libbpf: Add helpers to extract perf fd
 from bpf_link

On Fri, Aug 9, 2019 at 2:48 PM Daniel Xu <dxu@...uu.xyz> wrote:
>
> It is sometimes necessary to perform ioctl's on the underlying perf fd.
> There is not currently a way to extract the fd given a bpf_link, so add a
> a pair of casting and getting helpers.
>
> The casting and getting helpers are nice because they let us define
> broad categories of links that makes it clear to users what they can
> expect to extract from what type of link.
>
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---
>  tools/lib/bpf/libbpf.c   | 19 +++++++++++++++++++
>  tools/lib/bpf/libbpf.h   |  8 ++++++++
>  tools/lib/bpf/libbpf.map |  6 ++++++
>  3 files changed, 33 insertions(+)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index ead915aec349..f4d750863abd 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -4004,6 +4004,25 @@ static int bpf_link__destroy_perf_event(struct bpf_link *link)
>         return err;
>  }
>
> +const struct bpf_link_fd *bpf_link__as_fd(const struct bpf_link *link)
> +{
> +       if (!link)
> +               return NULL;

I'm not sure about all those NULL checks everywhere. It's not really a
Java, passing NULL is ok only to xxx__free() kind of functions,
everything else shouldn't expect to deal with NULLs correctly, IMO.

> +
> +       if (link->destroy != &bpf_link__destroy_perf_event)

While this is clever, it doesn't handle case for raw tracepoint
already. It is also anti-future proof, as when we add another use case
for bpf_link__fd with different destroy callback, we'll most probably
forget to update this function.

So let's instead introduce enum bpf_link_type and make it standard
part of "abstract" bpf_link. Please also add getter

enum bpf_link_type bpf_link__type(const struct bpf_link *link)
{
    return link->type;
}

to fetch it. That way users will also be able to write generic
functions potentially handling multiple kinds of bpf_links (and there
won't be a need to just "guess" the type of bpf_link).

> +               return NULL;
> +
> +       return (struct bpf_link_fd *)link;
> +}
> +
> +int bpf_link_fd__fd(const struct bpf_link_fd *link)
> +{
> +       if (!link)
> +               return -1;
> +
> +       return link->fd;
> +}
> +
>  struct bpf_link *bpf_program__attach_perf_event(struct bpf_program *prog,
>                                                 int pfd)
>  {
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 8a9d462a6f6d..4498b6ae459a 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -166,6 +166,14 @@ LIBBPF_API int bpf_program__unpin(struct bpf_program *prog, const char *path);
>  LIBBPF_API void bpf_program__unload(struct bpf_program *prog);
>
>  struct bpf_link;
> +struct bpf_link_fd;
> +
> +/* casting APIs */
> +LIBBPF_API const struct bpf_link_fd *
> +bpf_link__as_fd(const struct bpf_link *link);
> +
> +/* getters APIs */
> +LIBBPF_API int bpf_link_fd__fd(const struct bpf_link_fd *link);

But otherwise these new APIs look great, thanks!

>
>  LIBBPF_API int bpf_link__destroy(struct bpf_link *link);
>
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index f9d316e873d8..b58dd0f0259c 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -184,3 +184,9 @@ LIBBPF_0.0.4 {
>                 perf_buffer__new_raw;
>                 perf_buffer__poll;
>  } LIBBPF_0.0.3;
> +
> +LIBBPF_0.0.5 {
> +       global:
> +               bpf_link__as_fd;
> +               bpf_link_fd__fd;
> +} LIBBPF_0.0.4;
> --
> 2.20.1
>