1. 04 Sep, 2020 4 commits
    • Andrii Nakryiko's avatar
      libbpf: Make RELO_CALL work for multi-prog sections and sub-program calls · c3c55696
      Andrii Nakryiko authored
      This patch implements general and correct logic for bpf-to-bpf sub-program
      calls. Only sub-programs used (called into) from entry-point (main) BPF
      program are going to be appended at the end of main BPF program. This ensures
      that BPF verifier won't encounter any dead code due to copying unreferenced
      sub-program. This change means that each entry-point (main) BPF program might
      have a different set of sub-programs appended to it and potentially in
      different order. This has implications on how sub-program call relocations
      need to be handled, described below.
      
      All relocations are now split into two categores: data references (maps and
      global variables) and code references (sub-program calls). This distinction is
      important because data references need to be relocated just once per each BPF
      program and sub-program. These relocation are agnostic to instruction
      locations, because they are not code-relative and they are relocating against
      static targets (maps, variables with fixes offsets, etc).
      
      Sub-program RELO_CALL relocations, on the other hand, are highly-dependent on
      code position, because they are recorded as instruction-relative offset. So
      BPF sub-programs (those that do calls into other sub-programs) can't be
      relocated once, they need to be relocated each time such a sub-program is
      appended at the end of the main entry-point BPF program. As mentioned above,
      each main BPF program might have different subset and differen order of
      sub-programs, so call relocations can't be done just once. Splitting data
      reference and calls relocations as described above allows to do this
      efficiently and cleanly.
      
      bpf_object__find_program_by_name() will now ignore non-entry BPF programs.
      Previously one could have looked up '.text' fake BPF program, but the
      existence of such BPF program was always an implementation detail and you
      can't do much useful with it. Now, though, all non-entry sub-programs get
      their own BPF program with name corresponding to a function name, so there is
      no more '.text' name for BPF program. This means there is no regression,
      effectively, w.r.t.  API behavior. But this is important aspect to highlight,
      because it's going to be critical once libbpf implements static linking of BPF
      programs. Non-entry static BPF programs will be allowed to have conflicting
      names, but global and main-entry BPF program names should be unique. Just like
      with normal user-space linking process. So it's important to restrict this
      aspect right now, keep static and non-entry functions as internal
      implementation details, and not have to deal with regressions in behavior
      later.
      
      This patch leaves .BTF.ext adjustment as is until next patch.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200903203542.15944-5-andriin@fb.com
      c3c55696
    • Andrii Nakryiko's avatar
      libbpf: Support CO-RE relocations for multi-prog sections · db2b8b06
      Andrii Nakryiko authored
      Fix up CO-RE relocation code to handle relocations against ELF sections
      containing multiple BPF programs. This requires lookup of a BPF program by its
      section name and instruction index it contains. While it could have been done
      as a simple loop, it could run into performance issues pretty quickly, as
      number of CO-RE relocations can be quite large in real-world applications, and
      each CO-RE relocation incurs BPF program look up now. So instead of simple
      loop, implement a binary search by section name + insn offset.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200903203542.15944-4-andriin@fb.com
      db2b8b06
    • Andrii Nakryiko's avatar
      libbpf: Parse multi-function sections into multiple BPF programs · c1122392
      Andrii Nakryiko authored
      Teach libbpf how to parse code sections into potentially multiple bpf_program
      instances, based on ELF FUNC symbols. Each BPF program will keep track of its
      position within containing ELF section for translating section instruction
      offsets into program instruction offsets: regardless of BPF program's location
      in ELF section, it's first instruction is always at local instruction offset
      0, so when libbpf is working with relocations (which use section-based
      instruction offsets) this is critical to make proper translations.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200903203542.15944-3-andriin@fb.com
      c1122392
    • Andrii Nakryiko's avatar
      libbpf: Ensure ELF symbols table is found before further ELF processing · 0201c575
      Andrii Nakryiko authored
      libbpf ELF parsing logic might need symbols available before ELF parsing is
      completed, so we need to make sure that symbols table section is found in
      a separate pass before all the subsequent sections are processed.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200903203542.15944-2-andriin@fb.com
      0201c575
  2. 02 Sep, 2020 6 commits
  3. 01 Sep, 2020 15 commits
  4. 31 Aug, 2020 15 commits