1. 09 Mar, 2020 11 commits
  2. 05 Mar, 2020 6 commits
  3. 04 Mar, 2020 19 commits
  4. 03 Mar, 2020 4 commits
    • Alexei Starovoitov's avatar
      Merge branch 'bpf_link' · abbc61a5
      Alexei Starovoitov authored
      Andrii Nakryiko says:
      
      ====================
      This patch series adds bpf_link abstraction, analogous to libbpf's already
      existing bpf_link abstraction. This formalizes and makes more uniform existing
      bpf_link-like BPF program link (attachment) types (raw tracepoint and tracing
      links), which are FD-based objects that are automatically detached when last
      file reference is closed. These types of BPF program links are switched to
      using bpf_link framework.
      
      FD-based bpf_link approach provides great safety guarantees, by ensuring there
      is not going to be an abandoned BPF program attached, if user process suddenly
      exits or forgets to clean up after itself. This is especially important in
      production environment and is what all the recent new BPF link types followed.
      
      One of the previously existing  inconveniences of FD-based approach, though,
      was the scenario in which user process wants to install BPF link and exit, but
      let attached BPF program run. Now, with bpf_link abstraction in place, it's
      easy to support pinning links in BPF FS, which is done as part of the same
      patch #1. This allows FD-based BPF program links to survive exit of a user
      process and original file descriptor being closed, by creating an file entry
      in BPF FS. This provides great safety by default, with simple way to opt out
      for cases where it's needed.
      
      Corresponding libbpf APIs are added in the same patch set, as well as
      selftests for this functionality.
      
      Other types of BPF program attachments (XDP, cgroup, perf_event, etc) are
      going to be converted in subsequent patches to follow similar approach.
      
      v1->v2:
      - use bpf_link_new_fd() uniformly (Alexei).
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      abbc61a5
    • Andrii Nakryiko's avatar
      selftests/bpf: Add link pinning selftests · 6489b8e1
      Andrii Nakryiko authored
      Add selftests validating link pinning/unpinning and associated BPF link
      (attachment) lifetime.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200303043159.323675-4-andriin@fb.com
      6489b8e1
    • Andrii Nakryiko's avatar
      libbpf: Add bpf_link pinning/unpinning · c016b68e
      Andrii Nakryiko authored
      With bpf_link abstraction supported by kernel explicitly, add
      pinning/unpinning API for links. Also allow to create (open) bpf_link from BPF
      FS file.
      
      This API allows to have an "ephemeral" FD-based BPF links (like raw tracepoint
      or fexit/freplace attachments) surviving user process exit, by pinning them in
      a BPF FS, which is an important use case for long-running BPF programs.
      
      As part of this, expose underlying FD for bpf_link. While legacy bpf_link's
      might not have a FD associated with them (which will be expressed as
      a bpf_link with fd=-1), kernel's abstraction is based around FD-based usage,
      so match it closely. This, subsequently, allows to have a generic
      pinning/unpinning API for generalized bpf_link. For some types of bpf_links
      kernel might not support pinning, in which case bpf_link__pin() will return
      error.
      
      With FD being part of generic bpf_link, also get rid of bpf_link_fd in favor
      of using vanialla bpf_link.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200303043159.323675-3-andriin@fb.com
      c016b68e
    • Andrii Nakryiko's avatar
      bpf: Introduce pinnable bpf_link abstraction · 70ed506c
      Andrii Nakryiko authored
      Introduce bpf_link abstraction, representing an attachment of BPF program to
      a BPF hook point (e.g., tracepoint, perf event, etc). bpf_link encapsulates
      ownership of attached BPF program, reference counting of a link itself, when
      reference from multiple anonymous inodes, as well as ensures that release
      callback will be called from a process context, so that users can safely take
      mutex locks and sleep.
      
      Additionally, with a new abstraction it's now possible to generalize pinning
      of a link object in BPF FS, allowing to explicitly prevent BPF program
      detachment on process exit by pinning it in a BPF FS and let it open from
      independent other process to keep working with it.
      
      Convert two existing bpf_link-like objects (raw tracepoint and tracing BPF
      program attachments) into utilizing bpf_link framework, making them pinnable
      in BPF FS. More FD-based bpf_links will be added in follow up patches.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200303043159.323675-2-andriin@fb.com
      70ed506c