1. 16 7月, 2021 1 次提交
  2. 02 4月, 2021 1 次提交
  3. 22 7月, 2020 1 次提交
  4. 18 7月, 2020 1 次提交
  5. 08 7月, 2020 1 次提交
  6. 25 6月, 2020 1 次提交
  7. 23 6月, 2020 1 次提交
  8. 29 4月, 2020 1 次提交
    • A
      bpftool: Add bpf_link show and pin support · c5481f9a
      Andrii Nakryiko 提交于
      Add `bpftool link show` and `bpftool link pin` commands.
      
      Example plain output for `link show` (with showing pinned paths):
      
      [vmuser@archvm bpf]$ sudo ~/local/linux/tools/bpf/bpftool/bpftool -f link
      1: tracing  prog 12
              prog_type tracing  attach_type fentry
              pinned /sys/fs/bpf/my_test_link
              pinned /sys/fs/bpf/my_test_link2
      2: tracing  prog 13
              prog_type tracing  attach_type fentry
      3: tracing  prog 14
              prog_type tracing  attach_type fentry
      4: tracing  prog 15
              prog_type tracing  attach_type fentry
      5: tracing  prog 16
              prog_type tracing  attach_type fentry
      6: tracing  prog 17
              prog_type tracing  attach_type fentry
      7: raw_tracepoint  prog 21
              tp 'sys_enter'
      8: cgroup  prog 25
              cgroup_id 584  attach_type egress
      9: cgroup  prog 25
              cgroup_id 599  attach_type egress
      10: cgroup  prog 25
              cgroup_id 614  attach_type egress
      11: cgroup  prog 25
              cgroup_id 629  attach_type egress
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Reviewed-by: NQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20200429001614.1544-9-andriin@fb.com
      c5481f9a
  9. 14 3月, 2020 1 次提交
    • Q
      tools: bpftool: Restore message on failure to guess program type · 6ae32b29
      Quentin Monnet 提交于
      In commit 4a3d6c6a ("libbpf: Reduce log level for custom section
      names"), log level for messages for libbpf_attach_type_by_name() and
      libbpf_prog_type_by_name() was downgraded from "info" to "debug". The
      latter function, in particular, is used by bpftool when attempting to
      load programs, and this change caused bpftool to exit with no hint or
      error message when it fails to detect the type of the program to load
      (unless "-d" option was provided).
      
      To help users understand why bpftool fails to load the program, let's do
      a second run of the function with log level in "debug" mode in case of
      failure.
      
      Before:
      
          # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0
          # echo $?
          255
      
      Or really verbose with -d flag:
      
          # bpftool -d prog load sample_ret0.o /sys/fs/bpf/sample_ret0
          libbpf: loading sample_ret0.o
          libbpf: section(1) .strtab, size 134, link 0, flags 0, type=3
          libbpf: skip section(1) .strtab
          libbpf: section(2) .text, size 16, link 0, flags 6, type=1
          libbpf: found program .text
          libbpf: section(3) .debug_abbrev, size 55, link 0, flags 0, type=1
          libbpf: skip section(3) .debug_abbrev
          libbpf: section(4) .debug_info, size 75, link 0, flags 0, type=1
          libbpf: skip section(4) .debug_info
          libbpf: section(5) .rel.debug_info, size 32, link 14, flags 0, type=9
          libbpf: skip relo .rel.debug_info(5) for section(4)
          libbpf: section(6) .debug_str, size 150, link 0, flags 30, type=1
          libbpf: skip section(6) .debug_str
          libbpf: section(7) .BTF, size 155, link 0, flags 0, type=1
          libbpf: section(8) .BTF.ext, size 80, link 0, flags 0, type=1
          libbpf: section(9) .rel.BTF.ext, size 32, link 14, flags 0, type=9
          libbpf: skip relo .rel.BTF.ext(9) for section(8)
          libbpf: section(10) .debug_frame, size 40, link 0, flags 0, type=1
          libbpf: skip section(10) .debug_frame
          libbpf: section(11) .rel.debug_frame, size 16, link 14, flags 0, type=9
          libbpf: skip relo .rel.debug_frame(11) for section(10)
          libbpf: section(12) .debug_line, size 74, link 0, flags 0, type=1
          libbpf: skip section(12) .debug_line
          libbpf: section(13) .rel.debug_line, size 16, link 14, flags 0, type=9
          libbpf: skip relo .rel.debug_line(13) for section(12)
          libbpf: section(14) .symtab, size 96, link 1, flags 0, type=2
          libbpf: looking for externs among 4 symbols...
          libbpf: collected 0 externs total
          libbpf: failed to guess program type from ELF section '.text'
          libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...]
      
      After:
      
          # bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0
          libbpf: failed to guess program type from ELF section '.text'
          libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...]
      Signed-off-by: NQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200311021205.9755-1-quentin@isovalent.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
      6ae32b29
  10. 13 3月, 2020 1 次提交
  11. 21 1月, 2020 1 次提交
  12. 16 8月, 2019 1 次提交
  13. 09 8月, 2019 2 次提交
  14. 11 6月, 2019 1 次提交
  15. 29 1月, 2019 1 次提交
    • J
      tools: bpftool: fix crash with un-owned prog arrays · 8c79b356
      Jakub Kicinski 提交于
      Prog arrays don't have 'owner_prog_type' and 'owner_jited'
      fields in their fdinfo when they are created.  Those fields
      are set and reported when first program is checked for
      compatibility by bpf_prog_array_compatible().
      
      This means that bpftool cannot expect the fields to always
      be there.  Currently trying to show maps on a system with
      an un-owned prog array leads to a crash:
      
      $ bpftool map show
      389: prog_array  name tail_call_map  flags 0x0
      Error: key 'owner_prog_type' not found in fdinfo
      Error: key 'owner_jited' not found in fdinfo
             key 4B  value 4B  max_entries 4  memlock 4096B
             Segmentation fault (core dumped)
      
      We pass a NULL pointer to atoi().
      
      Remove the assumption that fdinfo keys are always present.
      Add missing validations and remove the p_err() calls which
      may lead to broken JSON output as caller will not propagate
      the failure.
      
      Fixes: 99a44bef ("tools: bpftool: add owner_prog_type and owner_jited to bpftool output")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      8c79b356
  16. 18 12月, 2018 2 次提交
  17. 15 12月, 2018 1 次提交
  18. 13 12月, 2018 1 次提交
  19. 01 12月, 2018 2 次提交
  20. 11 11月, 2018 1 次提交
  21. 09 11月, 2018 2 次提交
    • Q
      tools: bpftool: pass an argument to silence open_obj_pinned() · f120919f
      Quentin Monnet 提交于
      Function open_obj_pinned() prints error messages when it fails to open a
      link in the BPF virtual file system. However, in some occasions it is
      not desirable to print an error, for example when we parse all links
      under the bpffs root, and the error is due to some paths actually being
      symbolic links.
      
      Example output:
      
          # ls -l /sys/fs/bpf/
          lrwxrwxrwx 1 root root 0 Oct 18 19:00 ip -> /sys/fs/bpf/tc/
          drwx------ 3 root root 0 Oct 18 19:00 tc
          lrwxrwxrwx 1 root root 0 Oct 18 19:00 xdp -> /sys/fs/bpf/tc/
      
          # bpftool --bpffs prog show
          Error: bpf obj get (/sys/fs/bpf): Permission denied
          Error: bpf obj get (/sys/fs/bpf): Permission denied
      
          # strace -e bpf bpftool --bpffs prog show
          bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/ip", bpf_fd=0}, 72) = -1 EACCES (Permission denied)
          Error: bpf obj get (/sys/fs/bpf): Permission denied
          bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/xdp", bpf_fd=0}, 72) = -1 EACCES (Permission denied)
          Error: bpf obj get (/sys/fs/bpf): Permission denied
          ...
      
      To fix it, pass a bool as a second argument to the function, and prevent
      it from printing an error when the argument is set to true.
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      f120919f
    • Q
      tools: bpftool: prevent infinite loop in get_fdinfo() · 53909030
      Quentin Monnet 提交于
      Function getline() returns -1 on failure to read a line, thus creating
      an infinite loop in get_fdinfo() if the key is not found. Fix it by
      calling the function only as long as we get a strictly positive return
      value.
      
      Found by copying the code for a key which is not always present...
      
      Fixes: 71bb428f ("tools: bpf: add bpftool")
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      53909030
  22. 08 11月, 2018 1 次提交
    • Q
      tools: bpftool: adjust rlimit RLIMIT_MEMLOCK when loading programs, maps · 8302b9bd
      Quentin Monnet 提交于
      The limit for memory locked in the kernel by a process is usually set to
      64 kbytes by default. This can be an issue when creating large BPF maps
      and/or loading many programs. A workaround is to raise this limit for
      the current process before trying to create a new BPF map. Changing the
      hard limit requires the CAP_SYS_RESOURCE and can usually only be done by
      root user (for non-root users, a call to setrlimit fails (and sets
      errno) and the program simply goes on with its rlimit unchanged).
      
      There is no API to get the current amount of memory locked for a user,
      therefore we cannot raise the limit only when required. One solution,
      used by bcc, is to try to create the map, and on getting a EPERM error,
      raising the limit to infinity before giving another try. Another
      approach, used in iproute2, is to raise the limit in all cases, before
      trying to create the map.
      
      Here we do the same as in iproute2: the rlimit is raised to infinity
      before trying to load programs or to create maps with bpftool.
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      8302b9bd
  23. 19 10月, 2018 1 次提交
  24. 16 10月, 2018 1 次提交
  25. 20 7月, 2018 1 次提交
  26. 01 7月, 2018 1 次提交
  27. 05 5月, 2018 2 次提交
  28. 07 3月, 2018 1 次提交
  29. 18 1月, 2018 1 次提交
  30. 31 12月, 2017 1 次提交
  31. 14 12月, 2017 1 次提交
  32. 11 11月, 2017 2 次提交
    • P
      tools: bpftool: show filenames of pinned objects · 4990f1f4
      Prashant Bhole 提交于
      Added support to show filenames of pinned objects.
      
      For example:
      
      root@test# ./bpftool prog
      3: tracepoint  name tracepoint__irq  tag f677a7dd722299a3
          loaded_at Oct 26/11:39  uid 0
          xlated 160B  not jited  memlock 4096B  map_ids 4
          pinned /sys/fs/bpf/softirq_prog
      
      4: tracepoint  name tracepoint__irq  tag ea5dc530d00b92b6
          loaded_at Oct 26/11:39  uid 0
          xlated 392B  not jited  memlock 4096B  map_ids 4,6
      
      root@test# ./bpftool --json --pretty prog
      [{
              "id": 3,
              "type": "tracepoint",
              "name": "tracepoint__irq",
              "tag": "f677a7dd722299a3",
              "loaded_at": "Oct 26/11:39",
              "uid": 0,
              "bytes_xlated": 160,
              "jited": false,
              "bytes_memlock": 4096,
              "map_ids": [4
              ],
              "pinned": ["/sys/fs/bpf/softirq_prog"
              ]
          },{
              "id": 4,
              "type": "tracepoint",
              "name": "tracepoint__irq",
              "tag": "ea5dc530d00b92b6",
              "loaded_at": "Oct 26/11:39",
              "uid": 0,
              "bytes_xlated": 392,
              "jited": false,
              "bytes_memlock": 4096,
              "map_ids": [4,6
              ],
              "pinned": []
          }
      ]
      
      root@test# ./bpftool map
      4: hash  name start  flags 0x0
          key 4B  value 16B  max_entries 10240  memlock 1003520B
          pinned /sys/fs/bpf/softirq_map1
      5: hash  name iptr  flags 0x0
          key 4B  value 8B  max_entries 10240  memlock 921600B
      
      root@test# ./bpftool --json --pretty map
      [{
              "id": 4,
              "type": "hash",
              "name": "start",
              "flags": 0,
              "bytes_key": 4,
              "bytes_value": 16,
              "max_entries": 10240,
              "bytes_memlock": 1003520,
              "pinned": ["/sys/fs/bpf/softirq_map1"
              ]
          },{
              "id": 5,
              "type": "hash",
              "name": "iptr",
              "flags": 0,
              "bytes_key": 4,
              "bytes_value": 8,
              "max_entries": 10240,
              "bytes_memlock": 921600,
              "pinned": []
          }
      ]
      Signed-off-by: NPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4990f1f4
    • P
      tools: bpftool: open pinned object without type check · 18527196
      Prashant Bhole 提交于
      This was needed for opening any file in bpf-fs without knowing
      its object type
      Signed-off-by: NPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18527196
  33. 05 11月, 2017 1 次提交
  34. 26 10月, 2017 1 次提交