1. 26 Jan, 2019 14 commits
  2. 25 Jan, 2019 5 commits
  3. 24 Jan, 2019 15 commits
  4. 23 Jan, 2019 6 commits
    • Stanislav Fomichev's avatar
      selftests/bpf: don't hardcode iptables/nc path in test_tcpnotify_user · bbebce8e
      Stanislav Fomichev authored
      system() is calling shell which should find the appropriate full path
      via $PATH. On some systems, full path to iptables and/or nc might be
      different that we one we have hardcoded.
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      bbebce8e
    • Taeung Song's avatar
      libbpf: Show supported ELF section names when failing to guess prog/attach type · c76e4c22
      Taeung Song authored
      We need to let users check their wrong ELF section name with proper
      ELF section names when they fail to get a prog/attach type from it.
      Because users can't realize libbpf guess prog/attach types from given
      ELF section names. For example, when a 'cgroup' section name of a
      BPF program is used, show available ELF section names(types).
      
      Before:
      
          $ bpftool prog load bpf-prog.o /sys/fs/bpf/prog1
          Error: failed to guess program type based on ELF section name cgroup
      
      After:
      
          libbpf: failed to guess program type based on ELF section name 'cgroup'
          libbpf: supported section(type) names are: socket kprobe/ kretprobe/ classifier action tracepoint/ raw_tracepoint/ xdp perf_event lwt_in lwt_out lwt_xmit lwt_seg6local cgroup_skb/ingress cgroup_skb/egress cgroup/skb cgroup/sock cgroup/post_bind4 cgroup/post_bind6 cgroup/dev sockops sk_skb/stream_parser sk_skb/stream_verdict sk_skb sk_msg lirc_mode2 flow_dissector cgroup/bind4 cgroup/bind6 cgroup/connect4 cgroup/connect6 cgroup/sendmsg4 cgroup/sendmsg6
      Signed-off-by: default avatarTaeung Song <treeze.taeung@gmail.com>
      Cc: Quentin Monnet <quentin.monnet@netronome.com>
      Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
      Cc: Andrey Ignatov <rdna@fb.com>
      Reviewed-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      c76e4c22
    • Yonghong Song's avatar
      bpf: btf: add btf documentation · ffcf7ce9
      Yonghong Song authored
      This patch added documentation for BTF (BPF Debug Format).
      The document is placed under linux:Documentation/bpf directory.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      ffcf7ce9
    • Alexei Starovoitov's avatar
      Merge branch 'bpftool-probes' · cbeaad90
      Alexei Starovoitov authored
      Quentin Monnet says:
      
      ====================
      Hi,
      This set adds a new command to bpftool in order to dump a list of
      eBPF-related parameters for the system (or for a specific network
      device) to the console. Once again, this is based on a suggestion from
      Daniel.
      
      At this time, output includes:
      
          - Availability of bpf() system call
          - Availability of bpf() system call for unprivileged users
          - JIT status (enabled or not, with or without debugging traces)
          - JIT hardening status
          - JIT kallsyms exports status
          - Global memory limit for JIT compiler for unprivileged users
          - Status of kernel compilation options related to BPF features
          - Availability of known eBPF program types
          - Availability of known eBPF map types
          - Availability of known eBPF helper functions
      
      There are three different ways to dump this information at this time:
      
          - Plain output dumps probe results in plain text. It is the most
            flexible options for providing descriptive output to the user, but
            should not be relied upon for parsing the output.
          - JSON output is supported.
          - A third mode, available through the "macros" keyword appended to the
            command line, dumps some of those parameters (not all) as a series of
            "#define" directives, that can be included into a C header file for
            example.
      
      Probes for supported program and map types, and supported helpers, are
      directly added to libbpf, so that other applications (or selftests) can
      reuse them as necessary.
      
      If the user does not have root privileges (or more precisely, the
      CAP_SYS_ADMIN capability) detection will be erroneous for most
      parameters. Therefore, forbid non-root users to run the command.
      
      v5:
      - Move exported symbols to a new LIBBPF_0.0.2 section in libbpf.map
        (patches 4 to 6).
      - Minor fixes on patches 3 and 4.
      
      v4:
      - Probe bpf_jit_limit parameter (patch 2).
      - Probe some additional kernel config options (patch 3).
      - Minor fixes on patch 6.
      
      v3:
      - Do not probe kernel version in bpftool (just retrieve it to probe support
        for kprobes in libbpf).
      - Change the way results for helper support is displayed: now one list of
        compatible helpers for each program type (and C-style output gets a
        HAVE_PROG_TYPE_HELPER(prog_type, helper) macro to help with tests. See
        patches 6, 7.
      - Address other comments from feedback from v2 (please refer to individual
        patches' history).
      
      v2 (please also refer to individual patches' history):
      - Move probes for prog/map types, helpers, from bpftool to libbpf.
      - Move C-style output as a separate patch, and restrict it to a subset of
        collected information (bpf() availability, prog/map types, helpers).
      - Now probe helpers with all supported program types, and display a list of
        compatible program types (as supported on the system) for each helper.
      - NOT addressed: grouping compilation options for kernel into subsections
        (patch 3) (I don't see an easy way of grouping them at the moment, please
        see also the discussion on v1 thread).
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      cbeaad90
    • Quentin Monnet's avatar
      tools: bpftool: add bash completion for bpftool probes · 948703e8
      Quentin Monnet authored
      Add the bash completion related to the newly introduced "bpftool feature
      probe" command.
      Signed-off-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      948703e8
    • Quentin Monnet's avatar
      tools: bpftool: add probes for a network device · f9499fed
      Quentin Monnet authored
      bpftool gained support for probing the current system in order to see
      what program and map types, and what helpers are available on that
      system. This patch adds the possibility to pass an interface index to
      libbpf (and hence to the kernel) when trying to load the programs or to
      create the maps, in order to see what items a given network device can
      support.
      
      A new keyword "dev <ifname>" can be used as an alternative to "kernel"
      to indicate that the given device should be tested. If no target ("dev"
      or "kernel") is specified bpftool defaults to probing the kernel.
      
      Sample output:
      
          # bpftool -p feature probe dev lo
          {
              "syscall_config": {
                  "have_bpf_syscall": true
              },
              "program_types": {
                  "have_sched_cls_prog_type": false,
                  "have_xdp_prog_type": false
              },
              ...
          }
      
      As the target is a network device, /proc/ parameters and kernel
      configuration are NOT dumped. Availability of the bpf() syscall is
      still probed, so we can return early if that syscall is not usable
      (since there is no point in attempting the remaining probes in this
      case).
      
      Among the program types, only the ones that can be offloaded are probed.
      All map types are probed, as there is no specific rule telling which one
      could or could not be supported by a device in the future. All helpers
      are probed (but only for offload-able program types).
      
      Caveat: as bpftool does not attempt to attach programs to the device at
      the moment, probes do not entirely reflect what the device accepts:
      typically, for Netronome's nfp, results will announce that TC cls
      offload is available even if support has been deactivated (with e.g.
      ethtool -K eth1 hw-tc-offload off).
      
      v2:
      - All helpers are probed, whereas previous version would only probe the
        ones compatible with an offload-able program type. This is because we
        do not keep a default compatible program type for each helper anymore.
      Signed-off-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      f9499fed