1. 22 Oct, 2021 3 commits
  2. 21 Oct, 2021 14 commits
  3. 20 Oct, 2021 9 commits
  4. 19 Oct, 2021 7 commits
    • Kumar Kartikeya Dwivedi's avatar
      bpf: Silence Coverity warning for find_kfunc_desc_btf · 588cd7ef
      Kumar Kartikeya Dwivedi authored
      The helper function returns a pointer that in the failure case encodes
      an error in the struct btf pointer. The current code lead to Coverity
      warning about the use of the invalid pointer:
      
       *** CID 1507963:  Memory - illegal accesses  (USE_AFTER_FREE)
       /kernel/bpf/verifier.c: 1788 in find_kfunc_desc_btf()
       1782                          return ERR_PTR(-EINVAL);
       1783                  }
       1784
       1785                  kfunc_btf = __find_kfunc_desc_btf(env, offset, btf_modp);
       1786                  if (IS_ERR_OR_NULL(kfunc_btf)) {
       1787                          verbose(env, "cannot find module BTF for func_id %u\n", func_id);
       >>>      CID 1507963:  Memory - illegal accesses  (USE_AFTER_FREE)
       >>>      Using freed pointer "kfunc_btf".
       1788                          return kfunc_btf ?: ERR_PTR(-ENOENT);
       1789                  }
       1790                  return kfunc_btf;
       1791          }
       1792          return btf_vmlinux ?: ERR_PTR(-ENOENT);
       1793     }
      
      Daniel suggested the use of ERR_CAST so that the intended use is clear
      to Coverity, but on closer look it seems that we never return NULL from
      the helper. Andrii noted that since __find_kfunc_desc_btf already logs
      errors for all cases except btf_get_by_fd, it is much easier to add
      logging for that and remove the IS_ERR check altogether, returning
      directly from it.
      Suggested-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20211009040900.803436-1-memxor@gmail.com
      588cd7ef
    • Andrii Nakryiko's avatar
      Merge branch 'fixes for bpftool's Makefile' · 32fa0efa
      Andrii Nakryiko authored
      Quentin Monnet says:
      
      ====================
      
      This set contains one fix for bpftool's Makefile, to make sure that the
      headers internal to libbpf are installed properly even if we add more
      headers to the relevant Makefile variable in the future (although we'd like
      to avoid that if possible).
      
      The other patches aim at cleaning up the output from the Makefile, in
      particular when running the command "make" another time after bpftool is
      built.
      ====================
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      32fa0efa
    • Quentin Monnet's avatar
      bpftool: Turn check on zlib from a phony target into a conditional error · 062e1fc0
      Quentin Monnet authored
      One of bpftool's object files depends on zlib. To make sure we do not
      attempt to build that object when the library is not available, commit
      d66fa3c7 ("tools: bpftool: add feature check for zlib") introduced a
      feature check to detect whether zlib is present.
      
      This check comes as a rule for which the target ("zdep") is a
      nonexistent file (phony target), which means that the Makefile always
      attempts to rebuild it. It is mostly harmless. However, one side effect
      is that, on running again once bpftool is already built, make considers
      that "something" (the recipe for zdep) was executed, and does not print
      the usual message "make: Nothing to be done for 'all'", which is a
      user-friendly indicator that the build went fine.
      
      Before, with some level of debugging information:
      
          $ make --debug=m
          [...]
          Reading makefiles...
      
          Auto-detecting system features:
          ...                        libbfd: [ on  ]
          ...        disassembler-four-args: [ on  ]
          ...                          zlib: [ on  ]
          ...                        libcap: [ on  ]
          ...               clang-bpf-co-re: [ on  ]
      
          Updating makefiles....
          Updating goal targets....
           File 'all' does not exist.
                 File 'zdep' does not exist.
                Must remake target 'zdep'.
           File 'all' does not exist.
          Must remake target 'all'.
          Successfully remade target file 'all'.
      
      After the patch:
      
          $ make --debug=m
          [...]
      
          Auto-detecting system features:
          ...                        libbfd: [ on  ]
          ...        disassembler-four-args: [ on  ]
          ...                          zlib: [ on  ]
          ...                        libcap: [ on  ]
          ...               clang-bpf-co-re: [ on  ]
      
          Updating makefiles....
          Updating goal targets....
           File 'all' does not exist.
          Must remake target 'all'.
          Successfully remade target file 'all'.
          make: Nothing to be done for 'all'.
      
      (Note the last line, which is not part of make's debug information.)
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20211009210341.6291-4-quentin@isovalent.com
      062e1fc0
    • Quentin Monnet's avatar
      bpftool: Do not FORCE-build libbpf · ced846c6
      Quentin Monnet authored
      In bpftool's Makefile, libbpf has a FORCE dependency, to make sure we
      rebuild it in case its source files changed. Let's instead make the
      rebuild depend on the source files directly, through a call to the
      "$(wildcard ...)" function. This avoids descending into libbpf's
      directory if there is nothing to update.
      
      Do the same for the bootstrap libbpf version.
      
      This results in a slightly faster operation and less verbose output when
      running make a second time in bpftool's directory.
      
      Before:
      
          Auto-detecting system features:
          ...                        libbfd: [ on  ]
          ...        disassembler-four-args: [ on  ]
          ...                          zlib: [ on  ]
          ...                        libcap: [ on  ]
          ...               clang-bpf-co-re: [ on  ]
      
          make[1]: Entering directory '/root/dev/linux/tools/lib/bpf'
          make[1]: Entering directory '/root/dev/linux/tools/lib/bpf'
          make[1]: Nothing to be done for 'install_headers'.
          make[1]: Leaving directory '/root/dev/linux/tools/lib/bpf'
          make[1]: Leaving directory '/root/dev/linux/tools/lib/bpf'
      
      After:
      
          Auto-detecting system features:
          ...                        libbfd: [ on  ]
          ...        disassembler-four-args: [ on  ]
          ...                          zlib: [ on  ]
          ...                        libcap: [ on  ]
          ...               clang-bpf-co-re: [ on  ]
      
      Other ways to clean up the output could be to pass the "-s" option, or
      to redirect the output to >/dev/null, when calling make recursively to
      descend into libbpf's directory. However, this would suppress some
      useful output if something goes wrong during the build. A better
      alternative would be to pass "--no-print-directory" to the recursive
      make, but that would still leave us with some noise for
      "install_headers". Skipping the descent into libbpf's directory if no
      source file has changed works best, and seems the most logical option
      overall.
      Reported-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20211009210341.6291-3-quentin@isovalent.com
      ced846c6
    • Quentin Monnet's avatar
      bpftool: Fix install for libbpf's internal header(s) · 34e3ab14
      Quentin Monnet authored
      We recently updated bpftool's Makefile to make it install the headers
      from libbpf, instead of pulling them directly from libbpf's directory.
      There is also an additional header, internal to libbpf, that needs be
      installed. The way that bpftool's Makefile installs that particular
      header is currently correct, but would break if we were to modify
      $(LIBBPF_INTERNAL_HDRS) to make it point to more than one header.
      
      Use a static pattern rule instead, so that the Makefile can withstand
      the addition of other headers to install.
      
      The objective is simply to make the Makefile more robust. It should
      _not_ be read as an invitation to import more internal headers from
      libbpf into bpftool.
      
      Fixes: f012ade1 ("bpftool: Install libbpf headers instead of including the dir")
      Reported-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20211009210341.6291-2-quentin@isovalent.com
      34e3ab14
    • Quentin Monnet's avatar
      libbpf: Remove Makefile warnings on out-of-sync netlink.h/if_link.h · d51b6b22
      Quentin Monnet authored
      Although relying on some definitions from the netlink.h and if_link.h
      headers copied into tools/include/uapi/linux/, libbpf does not need
      those headers to stay entirely up-to-date with their original versions,
      and the warnings emitted by the Makefile when it detects a difference
      are usually just noise. Let's remove those warnings.
      Suggested-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20211010002528.9772-1-quentin@isovalent.com
      d51b6b22
    • Yonghong Song's avatar
      bpf: Rename BTF_KIND_TAG to BTF_KIND_DECL_TAG · 223f903e
      Yonghong Song authored
      Patch set [1] introduced BTF_KIND_TAG to allow tagging
      declarations for struct/union, struct/union field, var, func
      and func arguments and these tags will be encoded into
      dwarf. They are also encoded to btf by llvm for the bpf target.
      
      After BTF_KIND_TAG is introduced, we intended to use it
      for kernel __user attributes. But kernel __user is actually
      a type attribute. Upstream and internal discussion showed
      it is not a good idea to mix declaration attribute and
      type attribute. So we proposed to introduce btf_type_tag
      as a type attribute and existing btf_tag renamed to
      btf_decl_tag ([2]).
      
      This patch renamed BTF_KIND_TAG to BTF_KIND_DECL_TAG and some
      other declarations with *_tag to *_decl_tag to make it clear
      the tag is for declaration. In the future, BTF_KIND_TYPE_TAG
      might be introduced per [3].
      
       [1] https://lore.kernel.org/bpf/20210914223004.244411-1-yhs@fb.com/
       [2] https://reviews.llvm.org/D111588
       [3] https://reviews.llvm.org/D111199
      
      Fixes: b5ea834d ("bpf: Support for new btf kind BTF_KIND_TAG")
      Fixes: 5b84bd10 ("libbpf: Add support for BTF_KIND_TAG")
      Fixes: 5c07f2fe ("bpftool: Add support for BTF_KIND_TAG")
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20211012164838.3345699-1-yhs@fb.com
      223f903e
  5. 11 Oct, 2021 2 commits
  6. 09 Oct, 2021 1 commit
  7. 08 Oct, 2021 4 commits