1. 27 Feb, 2019 1 commit
    • Yonghong Song's avatar
      samples/bpf: workaround clang asm goto compilation errors · 217dd7c4
      Yonghong Song authored
      [ Upstream commit 6bf3bbe1 ]
      
      x86 compilation has required asm goto support since 4.17.
      Since clang does not support asm goto, at 4.17,
      Commit b1ae32db ("x86/cpufeature: Guard asm_volatile_goto usage
      for BPF compilation") worked around the issue by permitting an
      alternative implementation without asm goto for clang.
      
      At 5.0, more asm goto usages appeared.
        [yhs@148 x86]$ egrep -r asm_volatile_goto
        include/asm/cpufeature.h:     asm_volatile_goto("1: jmp 6f\n"
        include/asm/jump_label.h:     asm_volatile_goto("1:"
        include/asm/jump_label.h:     asm_volatile_goto("1:"
        include/asm/rmwcc.h:  asm_volatile_goto (fullop "; j" #cc " %l[cc_label]"     \
        include/asm/uaccess.h:        asm_volatile_goto("\n"                          \
        include/asm/uaccess.h:        asm_volatile_goto("\n"                          \
        [yhs@148 x86]$
      
      Compiling samples/bpf directories, most bpf programs failed
      compilation with error messages like:
        In file included from /home/yhs/work/bpf-next/samples/bpf/xdp_sample_pkts_kern.c:2:
        In file included from /home/yhs/work/bpf-next/include/linux/ptrace.h:6:
        In file included from /home/yhs/work/bpf-next/include/linux/sched.h:15:
        In file included from /home/yhs/work/bpf-next/include/linux/sem.h:5:
        In file included from /home/yhs/work/bpf-next/include/uapi/linux/sem.h:5:
        In file included from /home/yhs/work/bpf-next/include/linux/ipc.h:9:
        In file included from /home/yhs/work/bpf-next/include/linux/refcount.h:72:
        /home/yhs/work/bpf-next/arch/x86/include/asm/refcount.h:70:9: error: 'asm goto' constructs are not supported yet
              return GEN_BINARY_SUFFIXED_RMWcc(LOCK_PREFIX "subl",
                     ^
        /home/yhs/work/bpf-next/arch/x86/include/asm/rmwcc.h:67:2: note: expanded from macro 'GEN_BINARY_SUFFIXED_RMWcc'
              __GEN_RMWcc(op " %[val], %[var]\n\t" suffix, var, cc,           \
              ^
        /home/yhs/work/bpf-next/arch/x86/include/asm/rmwcc.h:21:2: note: expanded from macro '__GEN_RMWcc'
              asm_volatile_goto (fullop "; j" #cc " %l[cc_label]"             \
              ^
        /home/yhs/work/bpf-next/include/linux/compiler_types.h:188:37: note: expanded from macro 'asm_volatile_goto'
        #define asm_volatile_goto(x...) asm goto(x)
      
      Most implementation does not even provide an alternative
      implementation. And it is also not practical to make changes
      for each call site.
      
      This patch workarounded the asm goto issue by redefining the macro like below:
        #define asm_volatile_goto(x...) asm volatile("invalid use of asm_volatile_goto")
      
      If asm_volatile_goto is not used by bpf programs, which is typically the case, nothing bad
      will happen. If asm_volatile_goto is used by bpf programs, which is incorrect, the compiler
      will issue an error since "invalid use of asm_volatile_goto" is not valid assembly codes.
      
      With this patch, all bpf programs under samples/bpf can pass compilation.
      
      Note that bpf programs under tools/testing/selftests/bpf/ compiled fine as
      they do not access kernel internal headers.
      
      Fixes: e769742d ("Revert "x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs"")
      Fixes: 18fe5822 ("x86, asm: change the GEN_*_RMWcc() macros to not quote the condition")
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarYonghong Song <yhs@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      217dd7c4
  2. 15 Feb, 2019 1 commit
  3. 12 Feb, 2019 1 commit
  4. 26 Jan, 2019 1 commit
    • Daniel T. Lee's avatar
      samples: bpf: fix: error handling regarding kprobe_events · d8e74c74
      Daniel T. Lee authored
      [ Upstream commit 5a863813 ]
      
      Currently, kprobe_events failure won't be handled properly.
      Due to calling system() indirectly to write to kprobe_events,
      it can't be identified whether an error is derived from kprobe or system.
      
          // buf = "echo '%c:%s %s' >> /s/k/d/t/kprobe_events"
          err = system(buf);
          if (err < 0) {
              printf("failed to create kprobe ..");
              return -1;
          }
      
      For example, running ./tracex7 sample in ext4 partition,
      "echo p:open_ctree open_ctree >> /s/k/d/t/kprobe_events"
      gets 256 error code system() failure.
      => The error comes from kprobe, but it's not handled correctly.
      
      According to man of system(3), it's return value
      just passes the termination status of the child shell
      rather than treating the error as -1. (don't care success)
      
      Which means, currently it's not working as desired.
      (According to the upper code snippet)
      
          ex) running ./tracex7 with ext4 env.
          # Current Output
          sh: echo: I/O error
          failed to open event open_ctree
      
          # Desired Output
          failed to create kprobe 'open_ctree' error 'No such file or directory'
      
      The problem is, error can't be verified whether from child ps
      or system. But using write() directly can verify the command
      failure, and it will treat all error as -1. So I suggest using
      write() directly to 'kprobe_events' rather than calling system().
      Signed-off-by: Daniel T. Lee's avatarDaniel T. Lee <danieltimlee@gmail.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d8e74c74
  5. 11 Oct, 2018 1 commit
  6. 10 Oct, 2018 1 commit
  7. 04 Oct, 2018 1 commit
    • Bo YU's avatar
      bpf, tracex3_user: erase "ARRAY_SIZE" redefined · 20cdeb54
      Bo YU authored
      There is a warning when compiling bpf sample programs in sample/bpf:
      
        make -C /home/foo/bpf/samples/bpf/../../tools/lib/bpf/ RM='rm -rf' LDFLAGS= srctree=/home/foo/bpf/samples/bpf/../../ O=
          HOSTCC  /home/foo/bpf/samples/bpf/tracex3_user.o
        /home/foo/bpf/samples/bpf/tracex3_user.c:20:0: warning: "ARRAY_SIZE" redefined
         #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))
      
        In file included from /home/foo/bpf/samples/bpf/tracex3_user.c:18:0:
        ./tools/testing/selftests/bpf/bpf_util.h:48:0: note: this is the location of the previous definition
         # define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
      Signed-off-by: 's avatarBo YU <tsu.yubo@gmail.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      20cdeb54
  8. 02 Oct, 2018 1 commit
  9. 01 Oct, 2018 1 commit
    • Roman Gushchin's avatar
      samples/bpf: extend test_cgrp2_attach2 test to use per-cpu cgroup storage · 5fcbd29b
      Roman Gushchin authored
      This commit extends the test_cgrp2_attach2 test to cover per-cpu
      cgroup storage. Bpf program will use shared and per-cpu cgroup
      storages simultaneously, so a better coverage of corresponding
      core code will be achieved.
      
      Expected output:
        $ ./test_cgrp2_attach2
        Attached DROP prog. This ping in cgroup /foo should fail...
        ping: sendmsg: Operation not permitted
        Attached DROP prog. This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS prog. This ping in cgroup /foo/bar should pass...
        Detached PASS from /foo/bar while DROP is attached to /foo.
        This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS from /foo/bar and detached DROP from /foo.
        This ping in cgroup /foo/bar should pass...
        ### override:PASS
        ### multi:PASS
      Signed-off-by: 's avatarRoman Gushchin <guro@fb.com>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      5fcbd29b
  10. 21 Sep, 2018 1 commit
    • Prashant Bhole's avatar
      samples/bpf: fix compilation failure · 32c00979
      Prashant Bhole authored
      following commit:
      commit d58e468b ("flow_dissector: implements flow dissector BPF hook")
      added struct bpf_flow_keys which conflicts with the struct with
      same name in sockex2_kern.c and sockex3_kern.c
      
      similar to commit:
      commit 534e0e52 ("samples/bpf: fix a compilation failure")
      we tried the rename it "flow_keys" but it also conflicted with struct
      having same name in include/net/flow_dissector.h. Hence renaming the
      struct to "flow_key_record". Also, this commit doesn't fix the
      compilation error completely because the similar struct is present in
      sockex3_kern.c. Hence renaming it in both files sockex3_user.c and
      sockex3_kern.c
      Signed-off-by: 's avatarPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      32c00979
  11. 18 Sep, 2018 2 commits
  12. 31 Aug, 2018 2 commits
  13. 29 Aug, 2018 1 commit
  14. 16 Aug, 2018 1 commit
  15. 10 Aug, 2018 2 commits
  16. 09 Aug, 2018 1 commit
  17. 02 Aug, 2018 1 commit
    • Roman Gushchin's avatar
      samples/bpf: extend test_cgrp2_attach2 test to use cgroup storage · 28ba0687
      Roman Gushchin authored
      The test_cgrp2_attach test covers bpf cgroup attachment code well,
      so let's re-use it for testing allocation/releasing of cgroup storage.
      
      The extension is pretty straightforward: the bpf program will use
      the cgroup storage to save the number of transmitted bytes.
      
      Expected output:
        $ ./test_cgrp2_attach2
        Attached DROP prog. This ping in cgroup /foo should fail...
        ping: sendmsg: Operation not permitted
        Attached DROP prog. This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS prog. This ping in cgroup /foo/bar should pass...
        Detached PASS from /foo/bar while DROP is attached to /foo.
        This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS from /foo/bar and detached DROP from /foo.
        This ping in cgroup /foo/bar should pass...
        ### override:PASS
        ### multi:PASS
      Signed-off-by: 's avatarRoman Gushchin <guro@fb.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Acked-by: 's avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      28ba0687
  18. 27 Jul, 2018 4 commits
  19. 17 Jul, 2018 2 commits
  20. 16 Jul, 2018 2 commits
  21. 13 Jul, 2018 1 commit
  22. 11 Jul, 2018 1 commit
  23. 10 Jul, 2018 1 commit
  24. 05 Jul, 2018 4 commits
  25. 04 Jul, 2018 1 commit
  26. 03 Jul, 2018 1 commit
  27. 28 Jun, 2018 3 commits
    • David Ahern's avatar
      bpf: Change bpf_fib_lookup to return lookup status · 4c79579b
      David Ahern authored
      For ACLs implemented using either FIB rules or FIB entries, the BPF
      program needs the FIB lookup status to be able to drop the packet.
      Since the bpf_fib_lookup API has not reached a released kernel yet,
      change the return code to contain an encoding of the FIB lookup
      result and return the nexthop device index in the params struct.
      
      In addition, inform the BPF program of any post FIB lookup reason as
      to why the packet needs to go up the stack.
      
      The fib result for unicast routes must have an egress device, so remove
      the check that it is non-NULL.
      Signed-off-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      4c79579b
    • Jesper Dangaard Brouer's avatar
      samples/bpf: xdp_rxq_info action XDP_TX must adjust MAC-addrs · 509fda10
      Jesper Dangaard Brouer authored
      XDP_TX requires also changing the MAC-addrs, else some hardware
      may drop the TX packet before reaching the wire.  This was
      observed with driver mlx5.
      
      If xdp_rxq_info select --action XDP_TX the swapmac functionality
      is activated.  It is also possible to manually enable via cmdline
      option --swapmac.  This is practical if wanting to measure the
      overhead of writing/updating payload for other action types.
      Signed-off-by: 's avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: Toke Høiland-Jørgensen's avatarToke Høiland-Jørgensen <toke@toke.dk>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      509fda10
    • Jesper Dangaard Brouer's avatar
      samples/bpf: extend xdp_rxq_info to read packet payload · 0d25c43a
      Jesper Dangaard Brouer authored
      There is a cost associated with reading the packet data payload
      that this test ignored.  Add option --read to allow enabling
      reading part of the payload.
      
      This sample/tool helps us analyse an issue observed with a NIC
      mlx5 (ConnectX-5 Ex) and an Intel(R) Xeon(R) CPU E5-1650 v4.
      
      With no_touch of data:
      
      Running XDP on dev:mlx5p1 (ifindex:8) action:XDP_DROP options:no_touch
      XDP stats       CPU     pps         issue-pps
      XDP-RX CPU      0       14,465,157  0
      XDP-RX CPU      1       14,464,728  0
      XDP-RX CPU      2       14,465,283  0
      XDP-RX CPU      3       14,465,282  0
      XDP-RX CPU      4       14,464,159  0
      XDP-RX CPU      5       14,465,379  0
      XDP-RX CPU      total   86,789,992
      
      When not touching data, we observe that the CPUs have idle cycles.
      When reading data the CPUs are 100% busy in softirq.
      
      With reading data:
      
      Running XDP on dev:mlx5p1 (ifindex:8) action:XDP_DROP options:read
      XDP stats       CPU     pps         issue-pps
      XDP-RX CPU      0       9,620,639   0
      XDP-RX CPU      1       9,489,843   0
      XDP-RX CPU      2       9,407,854   0
      XDP-RX CPU      3       9,422,289   0
      XDP-RX CPU      4       9,321,959   0
      XDP-RX CPU      5       9,395,242   0
      XDP-RX CPU      total   56,657,828
      
      The effect seen above is a result of cache-misses occuring when
      more RXQs are being used.  Based on perf-event observations, our
      conclusion is that the CPUs DDIO (Direct Data I/O) choose to
      deliver packet into main memory, instead of L3-cache.  We also
      found, that this can be mitigated by either using less RXQs or by
      reducing NICs the RX-ring size.
      Signed-off-by: 's avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: Toke Høiland-Jørgensen's avatarToke Høiland-Jørgensen <toke@toke.dk>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      0d25c43a