1. 26 Jan, 2019 16 commits
  2. 25 Jan, 2019 5 commits
  3. 24 Jan, 2019 15 commits
  4. 23 Jan, 2019 4 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