1. 25 4月, 2018 1 次提交
  2. 20 4月, 2018 1 次提交
    • M
      bpf: btf: Add BTF tests · c0fa1b6c
      Martin KaFai Lau 提交于
      This patch tests the BTF loading, map_create with BTF
      and the changes in libbpf.
      
      -r: Raw tests that test raw crafted BTF data
      -f: Test LLVM compiled bpf prog with BTF data
      -g: Test BPF_OBJ_GET_INFO_BY_FD for btf_fd
      -p: Test pretty print
      
      The tools/testing/selftests/bpf/Makefile will probe
      for BTF support in llc and pahole before generating
      debug info (-g) and convert them to BTF.  You can supply
      the BTF supported binary through the following make variables:
      LLC, BTF_PAHOLE and LLVM_OBJCOPY.
      
      LLC: The lastest llc with -mattr=dwarfris support for the bpf target.
           It is only in the master of the llvm repo for now.
      BTF_PAHOLE: The modified pahole with BTF support:
      	    https://github.com/iamkafai/pahole/tree/btf
      	    To add a BTF section: "pahole -J bpf_prog.o"
      LLVM_OBJCOPY: Any llvm-objcopy should do
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NAlexei Starovoitov <ast@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      c0fa1b6c
  3. 19 4月, 2018 2 次提交
  4. 31 3月, 2018 3 次提交
    • A
      selftests/bpf: Selftest for sys_bind post-hooks. · 1d436885
      Andrey Ignatov 提交于
      Add selftest for attach types `BPF_CGROUP_INET4_POST_BIND` and
      `BPF_CGROUP_INET6_POST_BIND`.
      
      The main things tested are:
      * prog load behaves as expected (valid/invalid accesses in prog);
      * prog attach behaves as expected (load- vs attach-time attach types);
      * `BPF_CGROUP_INET_SOCK_CREATE` can be attached in a backward compatible
        way;
      * post-hooks return expected result and errno.
      
      Example:
        # ./test_sock
        Test case: bind4 load with invalid access: src_ip6 .. [PASS]
        Test case: bind4 load with invalid access: mark .. [PASS]
        Test case: bind6 load with invalid access: src_ip4 .. [PASS]
        Test case: sock_create load with invalid access: src_port .. [PASS]
        Test case: sock_create load w/o expected_attach_type (compat mode) ..
        [PASS]
        Test case: sock_create load w/ expected_attach_type .. [PASS]
        Test case: attach type mismatch bind4 vs bind6 .. [PASS]
        Test case: attach type mismatch bind6 vs bind4 .. [PASS]
        Test case: attach type mismatch default vs bind4 .. [PASS]
        Test case: attach type mismatch bind6 vs sock_create .. [PASS]
        Test case: bind4 reject all .. [PASS]
        Test case: bind6 reject all .. [PASS]
        Test case: bind6 deny specific IP & port .. [PASS]
        Test case: bind4 allow specific IP & port .. [PASS]
        Test case: bind4 allow all .. [PASS]
        Test case: bind6 allow all .. [PASS]
        Summary: 16 PASSED, 0 FAILED
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      1d436885
    • A
      selftests/bpf: Selftest for sys_connect hooks · 622adafb
      Andrey Ignatov 提交于
      Add selftest for BPF_CGROUP_INET4_CONNECT and BPF_CGROUP_INET6_CONNECT
      attach types.
      
      Try to connect(2) to specified IP:port and test that:
      * remote IP:port pair is overridden;
      * local end of connection is bound to specified IP.
      
      All combinations of IPv4/IPv6 and TCP/UDP are tested.
      
      Example:
        # tcpdump -pn -i lo -w connect.pcap 2>/dev/null &
        [1] 478
        # strace -qqf -e connect -o connect.trace ./test_sock_addr.sh
        Wait for testing IPv4/IPv6 to become available ... OK
        Load bind4 with invalid type (can pollute stderr) ... REJECTED
        Load bind4 with valid type ... OK
        Attach bind4 with invalid type ... REJECTED
        Attach bind4 with valid type ... OK
        Load connect4 with invalid type (can pollute stderr) libbpf: load bpf \
          program failed: Permission denied
        libbpf: -- BEGIN DUMP LOG ---
        libbpf:
        0: (b7) r2 = 23569
        1: (63) *(u32 *)(r1 +24) = r2
        2: (b7) r2 = 16777343
        3: (63) *(u32 *)(r1 +4) = r2
        invalid bpf_context access off=4 size=4
        [ 1518.404609] random: crng init done
      
        libbpf: -- END LOG --
        libbpf: failed to load program 'cgroup/connect4'
        libbpf: failed to load object './connect4_prog.o'
        ... REJECTED
        Load connect4 with valid type ... OK
        Attach connect4 with invalid type ... REJECTED
        Attach connect4 with valid type ... OK
        Test case #1 (IPv4/TCP):
                Requested: bind(192.168.1.254, 4040) ..
                   Actual: bind(127.0.0.1, 4444)
                Requested: connect(192.168.1.254, 4040) from (*, *) ..
                   Actual: connect(127.0.0.1, 4444) from (127.0.0.4, 56068)
        Test case #2 (IPv4/UDP):
                Requested: bind(192.168.1.254, 4040) ..
                   Actual: bind(127.0.0.1, 4444)
                Requested: connect(192.168.1.254, 4040) from (*, *) ..
                   Actual: connect(127.0.0.1, 4444) from (127.0.0.4, 56447)
        Load bind6 with invalid type (can pollute stderr) ... REJECTED
        Load bind6 with valid type ... OK
        Attach bind6 with invalid type ... REJECTED
        Attach bind6 with valid type ... OK
        Load connect6 with invalid type (can pollute stderr) libbpf: load bpf \
          program failed: Permission denied
        libbpf: -- BEGIN DUMP LOG ---
        libbpf:
        0: (b7) r6 = 0
        1: (63) *(u32 *)(r1 +12) = r6
        invalid bpf_context access off=12 size=4
      
        libbpf: -- END LOG --
        libbpf: failed to load program 'cgroup/connect6'
        libbpf: failed to load object './connect6_prog.o'
        ... REJECTED
        Load connect6 with valid type ... OK
        Attach connect6 with invalid type ... REJECTED
        Attach connect6 with valid type ... OK
        Test case #3 (IPv6/TCP):
                Requested: bind(face:b00c:1234:5678::abcd, 6060) ..
                   Actual: bind(::1, 6666)
                Requested: connect(face:b00c:1234:5678::abcd, 6060) from (*, *)
                   Actual: connect(::1, 6666) from (::6, 37458)
        Test case #4 (IPv6/UDP):
                Requested: bind(face:b00c:1234:5678::abcd, 6060) ..
                   Actual: bind(::1, 6666)
                Requested: connect(face:b00c:1234:5678::abcd, 6060) from (*, *)
                   Actual: connect(::1, 6666) from (::6, 39315)
        ### SUCCESS
        # egrep 'connect\(.*AF_INET' connect.trace | \
        > egrep -vw 'htons\(1025\)' | fold -b -s -w 72
        502   connect(7, {sa_family=AF_INET, sin_port=htons(4040),
        sin_addr=inet_addr("192.168.1.254")}, 128) = 0
        502   connect(8, {sa_family=AF_INET, sin_port=htons(4040),
        sin_addr=inet_addr("192.168.1.254")}, 128) = 0
        502   connect(9, {sa_family=AF_INET6, sin6_port=htons(6060),
        inet_pton(AF_INET6, "face:b00c:1234:5678::abcd", &sin6_addr),
        sin6_flowinfo=0, sin6_scope_id=0}, 128) = 0
        502   connect(10, {sa_family=AF_INET6, sin6_port=htons(6060),
        inet_pton(AF_INET6, "face:b00c:1234:5678::abcd", &sin6_addr),
        sin6_flowinfo=0, sin6_scope_id=0}, 128) = 0
        # fg
        tcpdump -pn -i lo -w connect.pcap 2> /dev/null
        # tcpdump -r connect.pcap -n tcp | cut -c 1-72
        reading from file connect.pcap, link-type EN10MB (Ethernet)
        17:57:40.383533 IP 127.0.0.4.56068 > 127.0.0.1.4444: Flags [S], seq 1333
        17:57:40.383566 IP 127.0.0.1.4444 > 127.0.0.4.56068: Flags [S.], seq 112
        17:57:40.383589 IP 127.0.0.4.56068 > 127.0.0.1.4444: Flags [.], ack 1, w
        17:57:40.384578 IP 127.0.0.1.4444 > 127.0.0.4.56068: Flags [R.], seq 1,
        17:57:40.403327 IP6 ::6.37458 > ::1.6666: Flags [S], seq 406513443, win
        17:57:40.403357 IP6 ::1.6666 > ::6.37458: Flags [S.], seq 2448389240, ac
        17:57:40.403376 IP6 ::6.37458 > ::1.6666: Flags [.], ack 1, win 342, opt
        17:57:40.404263 IP6 ::1.6666 > ::6.37458: Flags [R.], seq 1, ack 1, win
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      622adafb
    • A
      selftests/bpf: Selftest for sys_bind hooks · e50b0a6f
      Andrey Ignatov 提交于
      Add selftest to work with bpf_sock_addr context from
      `BPF_PROG_TYPE_CGROUP_SOCK_ADDR` programs.
      
      Try to bind(2) on IP:port and apply:
      * loads to make sure context can be read correctly, including narrow
        loads (byte, half) for IP and full-size loads (word) for all fields;
      * stores to those fields allowed by verifier.
      
      All combination from IPv4/IPv6 and TCP/UDP are tested.
      
      Both scenarios are tested:
      * valid programs can be loaded and attached;
      * invalid programs can be neither loaded nor attached.
      
      Test passes when expected data can be read from context in the
      BPF-program, and after the call to bind(2) socket is bound to IP:port
      pair that was written by BPF-program to the context.
      
      Example:
        # ./test_sock_addr
        Attached bind4 program.
        Test case #1 (IPv4/TCP):
                Requested: bind(192.168.1.254, 4040) ..
                   Actual: bind(127.0.0.1, 4444)
        Test case #2 (IPv4/UDP):
                Requested: bind(192.168.1.254, 4040) ..
                   Actual: bind(127.0.0.1, 4444)
        Attached bind6 program.
        Test case #3 (IPv6/TCP):
                Requested: bind(face:b00c:1234:5678::abcd, 6060) ..
                   Actual: bind(::1, 6666)
        Test case #4 (IPv6/UDP):
                Requested: bind(face:b00c:1234:5678::abcd, 6060) ..
                   Actual: bind(::1, 6666)
        ### SUCCESS
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      e50b0a6f
  5. 29 3月, 2018 1 次提交
  6. 20 3月, 2018 6 次提交
  7. 15 3月, 2018 1 次提交
  8. 27 2月, 2018 2 次提交
  9. 24 2月, 2018 2 次提交
    • D
      bpf: add various jit test cases · 23d191a8
      Daniel Borkmann 提交于
      Add few test cases that check the rnu-time results under JIT.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      23d191a8
    • D
      bpf: allow xadd only on aligned memory · ca369602
      Daniel Borkmann 提交于
      The requirements around atomic_add() / atomic64_add() resp. their
      JIT implementations differ across architectures. E.g. while x86_64
      seems just fine with BPF's xadd on unaligned memory, on arm64 it
      triggers via interpreter but also JIT the following crash:
      
        [  830.864985] Unable to handle kernel paging request at virtual address ffff8097d7ed6703
        [...]
        [  830.916161] Internal error: Oops: 96000021 [#1] SMP
        [  830.984755] CPU: 37 PID: 2788 Comm: test_verifier Not tainted 4.16.0-rc2+ #8
        [  830.991790] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.29 07/17/2017
        [  830.998998] pstate: 80400005 (Nzcv daif +PAN -UAO)
        [  831.003793] pc : __ll_sc_atomic_add+0x4/0x18
        [  831.008055] lr : ___bpf_prog_run+0x1198/0x1588
        [  831.012485] sp : ffff00001ccabc20
        [  831.015786] x29: ffff00001ccabc20 x28: ffff8017d56a0f00
        [  831.021087] x27: 0000000000000001 x26: 0000000000000000
        [  831.026387] x25: 000000c168d9db98 x24: 0000000000000000
        [  831.031686] x23: ffff000008203878 x22: ffff000009488000
        [  831.036986] x21: ffff000008b14e28 x20: ffff00001ccabcb0
        [  831.042286] x19: ffff0000097b5080 x18: 0000000000000a03
        [  831.047585] x17: 0000000000000000 x16: 0000000000000000
        [  831.052885] x15: 0000ffffaeca8000 x14: 0000000000000000
        [  831.058184] x13: 0000000000000000 x12: 0000000000000000
        [  831.063484] x11: 0000000000000001 x10: 0000000000000000
        [  831.068783] x9 : 0000000000000000 x8 : 0000000000000000
        [  831.074083] x7 : 0000000000000000 x6 : 000580d428000000
        [  831.079383] x5 : 0000000000000018 x4 : 0000000000000000
        [  831.084682] x3 : ffff00001ccabcb0 x2 : 0000000000000001
        [  831.089982] x1 : ffff8097d7ed6703 x0 : 0000000000000001
        [  831.095282] Process test_verifier (pid: 2788, stack limit = 0x0000000018370044)
        [  831.102577] Call trace:
        [  831.105012]  __ll_sc_atomic_add+0x4/0x18
        [  831.108923]  __bpf_prog_run32+0x4c/0x70
        [  831.112748]  bpf_test_run+0x78/0xf8
        [  831.116224]  bpf_prog_test_run_xdp+0xb4/0x120
        [  831.120567]  SyS_bpf+0x77c/0x1110
        [  831.123873]  el0_svc_naked+0x30/0x34
        [  831.127437] Code: 97fffe97 17ffffec 00000000 f9800031 (885f7c31)
      
      Reason for this is because memory is required to be aligned. In
      case of BPF, we always enforce alignment in terms of stack access,
      but not when accessing map values or packet data when the underlying
      arch (e.g. arm64) has CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS set.
      
      xadd on packet data that is local to us anyway is just wrong, so
      forbid this case entirely. The only place where xadd makes sense in
      fact are map values; xadd on stack is wrong as well, but it's been
      around for much longer. Specifically enforce strict alignment in case
      of xadd, so that we handle this case generically and avoid such crashes
      in the first place.
      
      Fixes: 17a52670 ("bpf: verifier (add verifier core)")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      ca369602
  10. 23 2月, 2018 1 次提交
    • D
      bpf, arm64: fix out of bounds access in tail call · 16338a9b
      Daniel Borkmann 提交于
      I recently noticed a crash on arm64 when feeding a bogus index
      into BPF tail call helper. The crash would not occur when the
      interpreter is used, but only in case of JIT. Output looks as
      follows:
      
        [  347.007486] Unable to handle kernel paging request at virtual address fffb850e96492510
        [...]
        [  347.043065] [fffb850e96492510] address between user and kernel address ranges
        [  347.050205] Internal error: Oops: 96000004 [#1] SMP
        [...]
        [  347.190829] x13: 0000000000000000 x12: 0000000000000000
        [  347.196128] x11: fffc047ebe782800 x10: ffff808fd7d0fd10
        [  347.201427] x9 : 0000000000000000 x8 : 0000000000000000
        [  347.206726] x7 : 0000000000000000 x6 : 001c991738000000
        [  347.212025] x5 : 0000000000000018 x4 : 000000000000ba5a
        [  347.217325] x3 : 00000000000329c4 x2 : ffff808fd7cf0500
        [  347.222625] x1 : ffff808fd7d0fc00 x0 : ffff808fd7cf0500
        [  347.227926] Process test_verifier (pid: 4548, stack limit = 0x000000007467fa61)
        [  347.235221] Call trace:
        [  347.237656]  0xffff000002f3a4fc
        [  347.240784]  bpf_test_run+0x78/0xf8
        [  347.244260]  bpf_prog_test_run_skb+0x148/0x230
        [  347.248694]  SyS_bpf+0x77c/0x1110
        [  347.251999]  el0_svc_naked+0x30/0x34
        [  347.255564] Code: 9100075a d280220a 8b0a002a d37df04b (f86b694b)
        [...]
      
      In this case the index used in BPF r3 is the same as in r1
      at the time of the call, meaning we fed a pointer as index;
      here, it had the value 0xffff808fd7cf0500 which sits in x2.
      
      While I found tail calls to be working in general (also for
      hitting the error cases), I noticed the following in the code
      emission:
      
        # bpftool p d j i 988
        [...]
        38:   ldr     w10, [x1,x10]
        3c:   cmp     w2, w10
        40:   b.ge    0x000000000000007c              <-- signed cmp
        44:   mov     x10, #0x20                      // #32
        48:   cmp     x26, x10
        4c:   b.gt    0x000000000000007c
        50:   add     x26, x26, #0x1
        54:   mov     x10, #0x110                     // #272
        58:   add     x10, x1, x10
        5c:   lsl     x11, x2, #3
        60:   ldr     x11, [x10,x11]                  <-- faulting insn (f86b694b)
        64:   cbz     x11, 0x000000000000007c
        [...]
      
      Meaning, the tests passed because commit ddb55992 ("arm64:
      bpf: implement bpf_tail_call() helper") was using signed compares
      instead of unsigned which as a result had the test wrongly passing.
      
      Change this but also the tail call count test both into unsigned
      and cap the index as u32. Latter we did as well in 90caccdd
      ("bpf: fix bpf_tail_call() x64 JIT") and is needed in addition here,
      too. Tested on HiSilicon Hi1616.
      
      Result after patch:
      
        # bpftool p d j i 268
        [...]
        38:	ldr	w10, [x1,x10]
        3c:	add	w2, w2, #0x0
        40:	cmp	w2, w10
        44:	b.cs	0x0000000000000080
        48:	mov	x10, #0x20                  	// #32
        4c:	cmp	x26, x10
        50:	b.hi	0x0000000000000080
        54:	add	x26, x26, #0x1
        58:	mov	x10, #0x110                 	// #272
        5c:	add	x10, x1, x10
        60:	lsl	x11, x2, #3
        64:	ldr	x11, [x10,x11]
        68:	cbz	x11, 0x0000000000000080
        [...]
      
      Fixes: ddb55992 ("arm64: bpf: implement bpf_tail_call() helper")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      16338a9b
  11. 22 2月, 2018 3 次提交
  12. 15 2月, 2018 3 次提交
  13. 14 2月, 2018 2 次提交
    • Y
      tools/bpf: adjust rlimit RLIMIT_MEMLOCK for test_tcpbpf_user · 615a9474
      Yonghong Song 提交于
      The default rlimit RLIMIT_MEMLOCK is 64KB. In certain cases,
      e.g. in a test machine mimicking our production system, this test may
      fail due to unable to charge the required memory for map creation:
         # ./test_tcpbpf_user
         libbpf: failed to create map (name: 'global_map'): Operation not permitted
         libbpf: failed to load object 'test_tcpbpf_kern.o'
         FAILED: load_bpf_file failed for: test_tcpbpf_kern.o
      
      Changing the default rlimit RLIMIT_MEMLOCK to unlimited makes
      the test always pass.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      615a9474
    • J
      selftests/bpf: fix Makefile for cgroup_helpers.c · 41757dcb
      Jesper Dangaard Brouer 提交于
      The current selftests Makefile construct result in cgroup_helpers.c
      gets compiled together with all the TEST_GEN_PROGS. And it also result
      in invoking the libbpf Makefile two times (tools/lib/bpf).
      
      These issues were introduced in commit 9d1f1594 ("bpf: move
      cgroup_helpers from samples/bpf/ to tools/testing/selftesting/bpf/").
      
      The only test program that requires the cgroup helpers is 'test_dev_cgroup'.
      
      Thus, create a make target $(OUTPUT)/test_dev_cgroup that extend[1]
      the 'prerequisite' for the 'stem' %-style pattern in ../lib.mk,
      for this particular test program.
      
      Reviewers notice the make-rules in tools/testing/selftests/lib.mk
      differ from the normal kernel kbuild rules, and it is practical
      to use 'make -p' to follow how these 'Implicit/static pattern stem'
      gets expanded.
      
      [1] https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
      
      Fixes: 9d1f1594 ("bpf: move cgroup_helpers from samples/bpf/ to tools/testing/selftesting/bpf/")
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      41757dcb
  14. 09 2月, 2018 2 次提交
  15. 08 2月, 2018 1 次提交
  16. 06 2月, 2018 1 次提交
    • Y
      tools/bpf: fix batch-mode test failure of test_xdp_redirect.sh · 7b4eb53d
      Yonghong Song 提交于
      The tests at tools/testing/selftests/bpf can run in patch mode, e.g.,
          make -C tools/testing/selftests/bpf run_tests
      
      With the batch mode, I experimented intermittent test failure of
      test_xdp_redirect.sh.
          ....
          selftests: test_xdp_redirect [PASS]
          selftests: test_xdp_redirect.sh [PASS]
          RTNETLINK answers: File exists
          selftests: test_xdp_meta [FAILED]
          selftests: test_xdp_meta.sh [FAIL]
          ....
      
      The following illustrates what caused the failure:
           (1). test_xdp_redirect creates veth pairs (veth1,veth11) and
                (veth2,veth22), and assign veth11 and veth22 to namespace
                ns1 and ns2 respectively.
           (2). at the end of test_xdp_redirect test, ns1 and ns2 are
                deleted. During this process, the deletion of actual
                namespace resources, including deletion of veth1{1} and veth2{2},
                is put into a workqueue to be processed asynchronously.
           (3). test_xdp_meta tries to create veth pair (veth1, veth2).
                The previous veth deletions in step (2) have not finished yet,
                and veth1 or veth2 may be still valid in the kernel, thus
                causing the failure.
      
      The fix is to explicitly delete the veth pair before test_xdp_redirect
      exits. Only one end of veth needs deletion as the kernel will delete
      the other end automatically. Also test_xdp_meta is also fixed in
      similar manner to avoid future potential issues.
      
      Fixes: 996139e8 ("selftests: bpf: add a test for XDP redirect")
      Fixes: 22c88526 ("bpf: improve selftests and add tests for meta pointer")
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      7b4eb53d
  17. 01 2月, 2018 2 次提交
    • D
      bpf: fix null pointer deref in bpf_prog_test_run_xdp · 65073a67
      Daniel Borkmann 提交于
      syzkaller was able to generate the following XDP program ...
      
        (18) r0 = 0x0
        (61) r5 = *(u32 *)(r1 +12)
        (04) (u32) r0 += (u32) 0
        (95) exit
      
      ... and trigger a NULL pointer dereference in ___bpf_prog_run()
      via bpf_prog_test_run_xdp() where this was attempted to run.
      
      Reason is that recent xdp_rxq_info addition to XDP programs
      updated all drivers, but not bpf_prog_test_run_xdp(), where
      xdp_buff is set up. Thus when context rewriter does the deref
      on the netdev it's NULL at runtime. Fix it by using xdp_rxq
      from loopback dev. __netif_get_rx_queue() helper can also be
      reused in various other locations later on.
      
      Fixes: 02dd3291 ("bpf: finally expose xdp_rxq_info to XDP bpf-programs")
      Reported-by: syzbot+1eb094057b338eb1fc00@syzkaller.appspotmail.com
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      65073a67
    • Y
      tools/bpf: permit selftests/bpf to be built in a different directory · 62a06994
      Yonghong Song 提交于
      Fix a couple of issues at tools/testing/selftests/bpf/Makefile so
      the following command
         make -C tools/testing/selftests/bpf OUTPUT=/home/yhs/tmp
      can put the built results into a different directory.
      
      Also add the built binary test_tcpbpf_user in the .gitignore file.
      
      Fixes: 6882804c ("selftests/bpf: add a test for overlapping packet range checks")
      Fixes: 9d1f1594 ("bpf: move cgroup_helpers from samples/bpf/ to tools/testing/selftesting/bpf/")
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      62a06994
  18. 27 1月, 2018 3 次提交
  19. 26 1月, 2018 3 次提交