1. 16 10月, 2019 2 次提交
  2. 13 10月, 2019 2 次提交
  3. 12 10月, 2019 2 次提交
  4. 10 10月, 2019 2 次提交
  5. 09 10月, 2019 2 次提交
  6. 06 10月, 2019 4 次提交
  7. 02 10月, 2019 1 次提交
  8. 26 9月, 2019 2 次提交
  9. 19 9月, 2019 1 次提交
  10. 31 8月, 2019 1 次提交
  11. 21 8月, 2019 3 次提交
  12. 18 8月, 2019 1 次提交
  13. 16 8月, 2019 1 次提交
    • A
      libbpf: make libbpf.map source of truth for libbpf version · dadb81d0
      Andrii Nakryiko 提交于
      Currently libbpf version is specified in 2 places: libbpf.map and
      Makefile. They easily get out of sync and it's very easy to update one,
      but forget to update another one. In addition, Github projection of
      libbpf has to maintain its own version which has to be remembered to be
      kept in sync manually, which is very error-prone approach.
      
      This patch makes libbpf.map a source of truth for libbpf version and
      uses shell invocation to parse out correct full and major libbpf version
      to use during build. Now we need to make sure that once new release
      cycle starts, we need to add (initially) empty section to libbpf.map
      with correct latest version.
      
      This also will make it possible to keep Github projection consistent
      with kernel sources version of libbpf by adopting similar parsing of
      version from libbpf.map.
      
      v2->v3:
      - grep -o + sort -rV (Andrey);
      
      v1->v2:
      - eager version vars evaluation (Jakub);
      - simplified version regex (Andrey);
      
      Cc: Andrey Ignatov <rdna@fb.com>
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      dadb81d0
  14. 14 8月, 2019 1 次提交
  15. 08 8月, 2019 4 次提交
  16. 02 8月, 2019 1 次提交
  17. 01 8月, 2019 1 次提交
  18. 30 7月, 2019 1 次提交
  19. 29 7月, 2019 1 次提交
  20. 28 7月, 2019 1 次提交
  21. 27 7月, 2019 1 次提交
    • A
      libbpf: fix erroneous multi-closing of BTF FD · 5d01ab7b
      Andrii Nakryiko 提交于
      Libbpf stores associated BTF FD per each instance of bpf_program. When
      program is unloaded, that FD is closed. This is wrong, because leads to
      a race and possibly closing of unrelated files, if application
      simultaneously opens new files while bpf_programs are unloaded.
      
      It's also unnecessary, because struct btf "owns" that FD, and
      btf__free(), called from bpf_object__close() will close it. Thus the fix
      is to never have per-program BTF FD and fetch it from obj->btf, when
      necessary.
      
      Fixes: 2993e051 ("tools/bpf: add support to read .BTF.ext sections")
      Reported-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      5d01ab7b
  22. 26 7月, 2019 1 次提交
  23. 24 7月, 2019 2 次提交
    • A
      libbpf: provide more helpful message on uninitialized global var · f2a3e4e9
      Andrii Nakryiko 提交于
      When BPF program defines uninitialized global variable, it's put into
      a special COMMON section. Libbpf will reject such programs, but will
      provide very unhelpful message with garbage-looking section index.
      
      This patch detects special section cases and gives more explicit error
      message.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      f2a3e4e9
    • I
      libbpf: fix using uninitialized ioctl results · decb705e
      Ilya Maximets 提交于
      'channels.max_combined' initialized only on ioctl success and
      errno is only valid on ioctl failure.
      
      The code doesn't produce any runtime issues, but makes memory
      sanitizers angry:
      
       Conditional jump or move depends on uninitialised value(s)
          at 0x55C056F: xsk_get_max_queues (xsk.c:336)
          by 0x55C05B2: xsk_create_bpf_maps (xsk.c:354)
          by 0x55C089F: xsk_setup_xdp_prog (xsk.c:447)
          by 0x55C0E57: xsk_socket__create (xsk.c:601)
        Uninitialised value was created by a stack allocation
          at 0x55C04CD: xsk_get_max_queues (xsk.c:318)
      
      Additionally fixed warning on uninitialized bytes in ioctl arguments:
      
       Syscall param ioctl(SIOCETHTOOL) points to uninitialised byte(s)
          at 0x648D45B: ioctl (in /usr/lib64/libc-2.28.so)
          by 0x55C0546: xsk_get_max_queues (xsk.c:330)
          by 0x55C05B2: xsk_create_bpf_maps (xsk.c:354)
          by 0x55C089F: xsk_setup_xdp_prog (xsk.c:447)
          by 0x55C0E57: xsk_socket__create (xsk.c:601)
        Address 0x1ffefff378 is on thread 1's stack
        in frame #1, created by xsk_get_max_queues (xsk.c:318)
        Uninitialised value was created by a stack allocation
          at 0x55C04CD: xsk_get_max_queues (xsk.c:318)
      
      CC: Magnus Karlsson <magnus.karlsson@intel.com>
      Fixes: 1cad0788 ("libbpf: add support for using AF_XDP sockets")
      Signed-off-by: NIlya Maximets <i.maximets@samsung.com>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      decb705e
  24. 22 7月, 2019 2 次提交