1. 05 11月, 2017 1 次提交
  2. 01 11月, 2017 1 次提交
  3. 29 10月, 2017 1 次提交
  4. 23 10月, 2017 1 次提交
    • A
      selftests/bpf: fix broken build of test_maps · e27afb84
      Alexei Starovoitov 提交于
      fix multiple build errors and warnings
      
      1.
      test_maps.c: In function ‘test_map_rdonly’:
      test_maps.c:1051:30: error: ‘BPF_F_RDONLY’ undeclared (first use in this function)
              MAP_SIZE, map_flags | BPF_F_RDONLY);
      
      2.
      test_maps.c:1048:6: warning: unused variable ‘i’ [-Wunused-variable]
        int i, fd, key = 0, value = 0;
      
      3.
      test_maps.c:1087:2: error: called object is not a function or function pointer
        assert(bpf_map_lookup_elem(fd, &key, &value) == -1 && errno == EPERM);
      
      4.
      ./bpf_helpers.h:72:11: error: use of undeclared identifier 'BPF_FUNC_getsockopt'
              (void *) BPF_FUNC_getsockopt;
      
      Fixes: e043325b ("bpf: Add tests for eBPF file mode")
      Fixes: 6e71b04a ("bpf: Add file mode configuration into bpf maps")
      Fixes: cd86d1fd ("bpf: Adding helper function bpf_getsockops")
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e27afb84
  5. 20 10月, 2017 1 次提交
  6. 18 10月, 2017 1 次提交
    • J
      bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP · 6710e112
      Jesper Dangaard Brouer 提交于
      The 'cpumap' is primarily used as a backend map for XDP BPF helper
      call bpf_redirect_map() and XDP_REDIRECT action, like 'devmap'.
      
      This patch implement the main part of the map.  It is not connected to
      the XDP redirect system yet, and no SKB allocation are done yet.
      
      The main concern in this patch is to ensure the datapath can run
      without any locking.  This adds complexity to the setup and tear-down
      procedure, which assumptions are extra carefully documented in the
      code comments.
      
      V2:
       - make sure array isn't larger than NR_CPUS
       - make sure CPUs added is a valid possible CPU
      
      V3: fix nitpicks from Jakub Kicinski <kubakici@wp.pl>
      
      V5:
       - Restrict map allocation to root / CAP_SYS_ADMIN
       - WARN_ON_ONCE if queue is not empty on tear-down
       - Return -EPERM on memlock limit instead of -ENOMEM
       - Error code in __cpu_map_entry_alloc() also handle ptr_ring_cleanup()
       - Moved cpu_map_enqueue() to next patch
      
      V6: all notice by Daniel Borkmann
       - Fix err return code in cpu_map_alloc() introduced in V5
       - Move cpu_possible() check after max_entries boundary check
       - Forbid usage initially in check_map_func_compatibility()
      
      V7:
       - Fix alloc error path spotted by Daniel Borkmann
       - Did stress test adding+removing CPUs from the map concurrently
       - Fixed refcnt issue on cpu_map_entry, kthread started too soon
       - Make sure packets are flushed during tear-down, involved use of
         rcu_barrier() and kthread_run only exit after queue is empty
       - Fix alloc error path in __cpu_map_entry_alloc() for ptr_ring
      
      V8:
       - Nitpicking comments and gramma by Edward Cree
       - Fix missing semi-colon introduced in V7 due to rebasing
       - Move struct bpf_cpu_map_entry members cpu+map_id to tracepoint patch
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6710e112
  7. 10 10月, 2017 1 次提交
  8. 08 10月, 2017 3 次提交
  9. 05 10月, 2017 1 次提交
  10. 29 9月, 2017 1 次提交
    • M
      bpf: libbpf: Provide basic API support to specify BPF obj name · 88cda1c9
      Martin KaFai Lau 提交于
      This patch extends the libbpf to provide API support to
      allow specifying BPF object name.
      
      In tools/lib/bpf/libbpf, the C symbol of the function
      and the map is used.  Regarding section name, all maps are
      under the same section named "maps".  Hence, section name
      is not a good choice for map's name.  To be consistent with
      map, bpf_prog also follows and uses its function symbol as
      the prog's name.
      
      This patch adds logic to collect function's symbols in libbpf.
      There is existing codes to collect the map's symbols and no change
      is needed.
      
      The bpf_load_program_name() and bpf_map_create_name() are
      added to take the name argument.  For the other bpf_map_create_xxx()
      variants, a name argument is directly added to them.
      
      In samples/bpf, bpf_load.c in particular, the symbol is also
      used as the map's name and the map symbols has already been
      collected in the existing code.  For bpf_prog, bpf_load.c does
      not collect the function symbol name.  We can consider to collect
      them later if there is a need to continue supporting the bpf_load.c.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NAlexei Starovoitov <ast@fb.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88cda1c9
  11. 27 9月, 2017 1 次提交
  12. 25 9月, 2017 1 次提交
    • I
      tools include: Sync kernel ABI headers with tooling headers · 549a3976
      Ingo Molnar 提交于
      Time for a sync with ABI/uapi headers with the upcoming v4.14 kernel.
      
      None of the ABI changes require any source code level changes to our
      existing in-kernel tooling code:
      
        - tools/arch/s390/include/uapi/asm/kvm.h:
      
            New KVM_S390_VM_TOD_EXT ABI, not used by in-kernel tooling.
      
        - tools/arch/x86/include/asm/cpufeatures.h:
          tools/arch/x86/include/asm/disabled-features.h:
      
            New PCID, SME and VGIF x86 CPU feature bits defined.
      
        - tools/include/asm-generic/hugetlb_encode.h:
          tools/include/uapi/asm-generic/mman-common.h:
          tools/include/uapi/linux/mman.h:
      
            Two new madvise() flags, plus a hugetlb system call mmap flags
            restructuring/extension changes.
      
        - tools/include/uapi/drm/drm.h:
          tools/include/uapi/drm/i915_drm.h:
      
            New drm_syncobj_create flags definitions, new drm_syncobj_wait
            and drm_syncobj_array ABIs. DRM_I915_PERF_* calls and a new
            I915_PARAM_HAS_EXEC_FENCE_ARRAY ABI for the Intel driver.
      
        - tools/include/uapi/linux/bpf.h:
      
            New bpf_sock fields (::mark and ::priority), new XDP_REDIRECT
            action, new kvm_ppc_smmu_info fields (::data_keys, instr_keys)
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Milian Wolff <milian.wolff@kdab.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yao Jin <yao.jin@linux.intel.com>
      Link: http://lkml.kernel.org/r/20170913073823.lxmi4c7ejqlfabjx@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      549a3976
  13. 29 8月, 2017 1 次提交
  14. 20 8月, 2017 1 次提交
  15. 17 8月, 2017 1 次提交
    • J
      bpf: sockmap sample program · 69e8cc13
      John Fastabend 提交于
      This program binds a program to a cgroup and then matches hard
      coded IP addresses and adds these to a sockmap.
      
      This will receive messages from the backend and send them to
      the client.
      
           client:X <---> frontend:10000 client:X <---> backend:10001
      
      To keep things simple this is only designed for 1:1 connections
      using hard coded values. A more complete example would allow many
      backends and clients.
      
      To run,
      
       # sockmap <cgroup2_dir>
      Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69e8cc13
  16. 10 8月, 2017 1 次提交
    • D
      bpf: add BPF_J{LT,LE,SLT,SLE} instructions · 92b31a9a
      Daniel Borkmann 提交于
      Currently, eBPF only understands BPF_JGT (>), BPF_JGE (>=),
      BPF_JSGT (s>), BPF_JSGE (s>=) instructions, this means that
      particularly *JLT/*JLE counterparts involving immediates need
      to be rewritten from e.g. X < [IMM] by swapping arguments into
      [IMM] > X, meaning the immediate first is required to be loaded
      into a register Y := [IMM], such that then we can compare with
      Y > X. Note that the destination operand is always required to
      be a register.
      
      This has the downside of having unnecessarily increased register
      pressure, meaning complex program would need to spill other
      registers temporarily to stack in order to obtain an unused
      register for the [IMM]. Loading to registers will thus also
      affect state pruning since we need to account for that register
      use and potentially those registers that had to be spilled/filled
      again. As a consequence slightly more stack space might have
      been used due to spilling, and BPF programs are a bit longer
      due to extra code involving the register load and potentially
      required spill/fills.
      
      Thus, add BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<), BPF_JSLE (s<=)
      counterparts to the eBPF instruction set. Modifying LLVM to
      remove the NegateCC() workaround in a PoC patch at [1] and
      allowing it to also emit the new instructions resulted in
      cilium's BPF programs that are injected into the fast-path to
      have a reduced program length in the range of 2-3% (e.g.
      accumulated main and tail call sections from one of the object
      file reduced from 4864 to 4729 insns), reduced complexity in
      the range of 10-30% (e.g. accumulated sections reduced in one
      of the cases from 116432 to 88428 insns), and reduced stack
      usage in the range of 1-5% (e.g. accumulated sections from one
      of the object files reduced from 824 to 784b).
      
      The modification for LLVM will be incorporated in a backwards
      compatible way. Plan is for LLVM to have i) a target specific
      option to offer a possibility to explicitly enable the extension
      by the user (as we have with -m target specific extensions today
      for various CPU insns), and ii) have the kernel checked for
      presence of the extensions and enable them transparently when
      the user is selecting more aggressive options such as -march=native
      in a bpf target context. (Other frontends generating BPF byte
      code, e.g. ply can probe the kernel directly for its code
      generation.)
      
        [1] https://github.com/borkmann/llvm/tree/bpf-insnsSigned-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92b31a9a
  17. 09 8月, 2017 1 次提交
  18. 01 8月, 2017 1 次提交
    • A
      tools headers: Fixup tools/include/uapi/linux/bpf.h copy of kernel ABI header · f1d6cb2d
      Arnaldo Carvalho de Melo 提交于
      In 04df41e3 ("bpf: update tools/include/uapi/linux/bpf.h") the files
      added in 40304b2a ("bpf: BPF support for sock_ops") were added to
      tools/include, but not in a verbatim way, missing the comments, which
      ends up triggering this warning when build tools/perf/:
      
        make: Entering directory '/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
        Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'
      
      Make sure the the lines are equal, to fix the simple header copy
      drift detector in tools/perf/.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Lawrence Brakmo <brakmo@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: 04df41e3 ("bpf: update tools/include/uapi/linux/bpf.h")
      Link: http://lkml.kernel.org/n/tip-z9qyyqht9qq3yyxu76sfy0dh@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f1d6cb2d
  19. 31 7月, 2017 1 次提交
  20. 30 7月, 2017 1 次提交
  21. 03 7月, 2017 1 次提交
  22. 02 7月, 2017 1 次提交
  23. 11 6月, 2017 1 次提交
  24. 07 6月, 2017 1 次提交
  25. 05 6月, 2017 1 次提交
  26. 12 5月, 2017 1 次提交
  27. 22 4月, 2017 1 次提交
  28. 10 4月, 2017 1 次提交
  29. 02 4月, 2017 1 次提交
  30. 24 3月, 2017 2 次提交
  31. 23 3月, 2017 1 次提交
  32. 15 2月, 2017 1 次提交
  33. 11 2月, 2017 1 次提交
    • M
      tools: Sync {,tools/}include/uapi/linux/bpf.h · 9a738266
      Mickaël Salaün 提交于
      The tools version of this header is out of date; update it to the latest
      version from kernel header.
      
      Synchronize with the following commits:
      * b95a5c4d ("bpf: add a longest prefix match trie map implementation")
      * a5e8c070 ("bpf: add bpf_probe_read_str helper")
      * d1b662ad ("bpf: allow option for setting bpf_l4_csum_replace from scratch")
      Signed-off-by: NMickaël Salaün <mic@digikod.net>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Daniel Mack <daniel@zonque.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Gianluca Borello <g.borello@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a738266
  34. 16 12月, 2016 1 次提交
  35. 06 10月, 2016 1 次提交
  36. 09 8月, 2016 1 次提交
    • A
      toops: Sync tools/include/uapi/linux/bpf.h with the kernel · 791cceb8
      Arnaldo Carvalho de Melo 提交于
      The way we're using kernel headers in tools/ now, with a copy that is
      made to the same path prefixed by "tools/" plus checking if that copy
      got stale, i.e. if the kernel counterpart changed, helps in keeping
      track with new features that may be useful for tools to exploit.
      
      For instance, looking at all the changes to bpf.h since it was last
      copied to tools/include brings this to toolers' attention:
      
      Need to investigate this one to check how to run a program via perf, setting up
      a BPF event, that will take advantage of the way perf already calls clang/LLVM,
      sets up the event and runs the workload in a single command line, helping in
      debugging such semi cooperative programs:
      
        96ae5227 ("bpf: Add bpf_probe_write_user BPF helper to be called in tracers")
      
      This one needs further investigation about using the feature it improves
      in 'perf trace' to do some tcpdumpin' mixed with syscalls, tracepoints,
      probe points, callgraphs, etc:
      
        555c8a86 ("bpf: avoid stack copy and use skb ctx for event output")
      
      Add tracing just packets that are related to some container to that mix:
      
        4a482f34 ("cgroup: bpf: Add bpf_skb_in_cgroup_proto")
        4ed8ec52 ("cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY")
      
      Definetely needs to have example programs accessing task_struct from a bpf proggie
      started from 'perf trace':
      
        606274c5 ("bpf: introduce bpf_get_current_task() helper")
      
      Core networking related, XDP:
      
        6ce96ca3 ("bpf: add XDP_TX xdp_action for direct forwarding")
        6a773a15 ("bpf: add XDP prog type for early driver filter")
        13c5c240 ("bpf: add bpf_get_hash_recalc helper")
        d2485c42 ("bpf: add bpf_skb_change_type helper")
        6578171a ("bpf: add bpf_skb_change_proto helper")
      
      Changes detected by the tools build system:
      
        $ make -C tools/perf O=/tmp/build/perf install-bin
        make: Entering directory '/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
        Warning: tools/include/uapi/linux/bpf.h differs from kernel
          INSTALL  GTK UI
          CC       /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
        <SNIP>
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Brenden Blanco <bblanco@plumgrid.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Sargun Dhillon <sargun@sargun.me>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-difq4ts1xvww6eyfs9e7zlft@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      791cceb8
  37. 13 7月, 2016 1 次提交