enable BPF_PROG_TEST_RUN for raw_tp by kernel-patches-bot · Pull Request #112 · kernel-patches/bpf

kernel-patches-bot · 2020-09-25T21:01:20Z

Pull request for series with
subject: enable BPF_PROG_TEST_RUN for raw_tp
version: 6
url: https://patchwork.ozlabs.org/project/netdev/list/?series=204246

kernel-patches-bot · 2020-09-25T21:01:21Z

Master branch: 182bf3f
series: https://patchwork.ozlabs.org/project/netdev/list/?series=204246
version: 6

kernel-patches-bot · 2020-09-25T21:20:20Z

Master branch: 84085f8
series: https://patchwork.ozlabs.org/project/netdev/list/?series=204246
version: 6

kernel-patches-bot · 2020-09-26T00:06:45Z

Master branch: 99d4def
series: https://patchwork.ozlabs.org/project/netdev/list/?series=204246
version: 6

kernel-patches-bot · 2020-09-26T00:16:32Z

Master branch: ba5f4cf
series: https://patchwork.ozlabs.org/project/netdev/list/?series=204246
version: 6

kernel-patches-bot · 2020-09-26T00:35:22Z

Master branch: ba5f4cf
series: https://patchwork.ozlabs.org/project/netdev/list/?series=204246
version: 6

Pull request is NOT updated. Failed to apply https://patchwork.ozlabs.org/project/netdev/list/?series=204246, error message:
Cmd('git') failed due to: exit code(128)
cmdline: git am -3
stderr: 'fatal: previous rebase directory .git/rebase-apply still exists but mbox given.'

Add .test_run for raw_tracepoint. Also, introduce a new feature that runs the target program on a specific CPU. This is achieved by a new flag in bpf_attr.test, BPF_F_TEST_RUN_ON_CPU. When this flag is set, the program is triggered on cpu with id bpf_attr.test.cpu. This feature is needed for BPF programs that handle perf_event and other percpu resources, as the program can access these resource locally. Acked-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Song Liu <songliubraving@fb.com>

Add bpf_prog_test_run_opts() with support of new fields in bpf_attr.test, namely, flags and cpu. Also extend _opts operations to support outputs via opts. Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Song Liu <songliubraving@fb.com>

This test runs test_run for raw_tracepoint program. The test covers ctx input, retval output, and running on correct cpu. Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Song Liu <songliubraving@fb.com>

kernel-patches-bot · 2020-09-28T19:25:14Z

Master branch: 1fd17c8
series: https://patchwork.ozlabs.org/project/netdev/list/?series=204246
version: 6

kernel-patches-bot · 2020-09-28T19:56:39Z

At least one diff in series https://patchwork.ozlabs.org/project/netdev/list/?series=204246 irrelevant now. Closing PR.

The BPF STX/LDX instruction uses offset relative to the FP to address stack space. Since the BPF_FP locates at the top of the frame, the offset is usually a negative number. However, arm64 str/ldr immediate instruction requires that offset be a positive number. Therefore, this patch tries to convert the offsets. The method is to find the negative offset furthest from the FP firstly. Then add it to the FP, calculate a bottom position, called FPB, and then adjust the offsets in other STR/LDX instructions relative to FPB. FPB is saved using the callee-saved register x27 of arm64 which is not used yet. Before adjusting the offset, the patch checks every instruction to ensure that the FP does not change in run-time. If the FP may change, no offset is adjusted. For example, for the following bpftrace command: bpftrace -e 'kprobe:do_sys_open { printf("opening: %s\n", str(arg1)); }' Without this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: mov x25, sp 1c: mov x26, #0x0 // #0 20: bti j 24: sub sp, sp, #0x90 28: add x19, x0, #0x0 2c: mov x0, #0x0 // #0 30: mov x10, #0xffffffffffffff78 // #-136 34: str x0, [x25, x10] 38: mov x10, #0xffffffffffffff80 // #-128 3c: str x0, [x25, x10] 40: mov x10, #0xffffffffffffff88 // #-120 44: str x0, [x25, x10] 48: mov x10, #0xffffffffffffff90 // #-112 4c: str x0, [x25, x10] 50: mov x10, #0xffffffffffffff98 // #-104 54: str x0, [x25, x10] 58: mov x10, #0xffffffffffffffa0 // #-96 5c: str x0, [x25, x10] 60: mov x10, #0xffffffffffffffa8 // #-88 64: str x0, [x25, x10] 68: mov x10, #0xffffffffffffffb0 // #-80 6c: str x0, [x25, x10] 70: mov x10, #0xffffffffffffffb8 // #-72 74: str x0, [x25, x10] 78: mov x10, #0xffffffffffffffc0 // #-64 7c: str x0, [x25, x10] 80: mov x10, #0xffffffffffffffc8 // #-56 84: str x0, [x25, x10] 88: mov x10, #0xffffffffffffffd0 // #-48 8c: str x0, [x25, x10] 90: mov x10, #0xffffffffffffffd8 // #-40 94: str x0, [x25, x10] 98: mov x10, #0xffffffffffffffe0 // #-32 9c: str x0, [x25, x10] a0: mov x10, #0xffffffffffffffe8 // #-24 a4: str x0, [x25, x10] a8: mov x10, #0xfffffffffffffff0 // #-16 ac: str x0, [x25, x10] b0: mov x10, #0xfffffffffffffff8 // #-8 b4: str x0, [x25, x10] b8: mov x10, #0x8 // #8 bc: ldr x2, [x19, x10] [...] With this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: stp x27, x28, [sp, #-16]! 1c: mov x25, sp 20: sub x27, x25, #0x88 24: mov x26, #0x0 // #0 28: bti j 2c: sub sp, sp, #0x90 30: add x19, x0, #0x0 34: mov x0, #0x0 // #0 38: str x0, [x27] 3c: str x0, [x27, #8] 40: str x0, [x27, #16] 44: str x0, [x27, #24] 48: str x0, [x27, #32] 4c: str x0, [x27, #40] 50: str x0, [x27, #48] 54: str x0, [x27, #56] 58: str x0, [x27, #64] 5c: str x0, [x27, #72] 60: str x0, [x27, #80] 64: str x0, [x27, #88] 68: str x0, [x27, #96] 6c: str x0, [x27, #104] 70: str x0, [x27, #112] 74: str x0, [x27, #120] 78: str x0, [x27, #128] 7c: ldr x2, [x19, #8] [...] Signed-off-by: Xu Kuohai <xukuohai@huawei.com>

The BPF STX/LDX instruction uses offset relative to the FP to address stack space. Since the BPF_FP locates at the top of the frame, the offset is usually a negative number. However, arm64 str/ldr immediate instruction requires that offset be a positive number. Therefore, this patch tries to convert the offsets. The method is to find the negative offset furthest from the FP firstly. Then add it to the FP, calculate a bottom position, called FPB, and then adjust the offsets in other STR/LDX instructions relative to FPB. FPB is saved using the callee-saved register x27 of arm64 which is not used yet. Before adjusting the offset, the patch checks every instruction to ensure that the FP does not change in run-time. If the FP may change, no offset is adjusted. For example, for the following bpftrace command: bpftrace -e 'kprobe:do_sys_open { printf("opening: %s\n", str(arg1)); }' Without this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: mov x25, sp 1c: mov x26, #0x0 // #0 20: bti j 24: sub sp, sp, #0x90 28: add x19, x0, #0x0 2c: mov x0, #0x0 // #0 30: mov x10, #0xffffffffffffff78 // #-136 34: str x0, [x25, x10] 38: mov x10, #0xffffffffffffff80 // #-128 3c: str x0, [x25, x10] 40: mov x10, #0xffffffffffffff88 // #-120 44: str x0, [x25, x10] 48: mov x10, #0xffffffffffffff90 // #-112 4c: str x0, [x25, x10] 50: mov x10, #0xffffffffffffff98 // #-104 54: str x0, [x25, x10] 58: mov x10, #0xffffffffffffffa0 // #-96 5c: str x0, [x25, x10] 60: mov x10, #0xffffffffffffffa8 // #-88 64: str x0, [x25, x10] 68: mov x10, #0xffffffffffffffb0 // #-80 6c: str x0, [x25, x10] 70: mov x10, #0xffffffffffffffb8 // #-72 74: str x0, [x25, x10] 78: mov x10, #0xffffffffffffffc0 // #-64 7c: str x0, [x25, x10] 80: mov x10, #0xffffffffffffffc8 // #-56 84: str x0, [x25, x10] 88: mov x10, #0xffffffffffffffd0 // #-48 8c: str x0, [x25, x10] 90: mov x10, #0xffffffffffffffd8 // #-40 94: str x0, [x25, x10] 98: mov x10, #0xffffffffffffffe0 // #-32 9c: str x0, [x25, x10] a0: mov x10, #0xffffffffffffffe8 // #-24 a4: str x0, [x25, x10] a8: mov x10, #0xfffffffffffffff0 // #-16 ac: str x0, [x25, x10] b0: mov x10, #0xfffffffffffffff8 // #-8 b4: str x0, [x25, x10] b8: mov x10, #0x8 // #8 bc: ldr x2, [x19, x10] [...] With this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: stp x27, x28, [sp, #-16]! 1c: mov x25, sp 20: sub x27, x25, #0x88 24: mov x26, #0x0 // #0 28: bti j 2c: sub sp, sp, #0x90 30: add x19, x0, #0x0 34: mov x0, #0x0 // #0 38: str x0, [x27] 3c: str x0, [x27, #8] 40: str x0, [x27, #16] 44: str x0, [x27, #24] 48: str x0, [x27, #32] 4c: str x0, [x27, #40] 50: str x0, [x27, #48] 54: str x0, [x27, #56] 58: str x0, [x27, #64] 5c: str x0, [x27, #72] 60: str x0, [x27, #80] 64: str x0, [x27, #88] 68: str x0, [x27, #96] 6c: str x0, [x27, #104] 70: str x0, [x27, #112] 74: str x0, [x27, #120] 78: str x0, [x27, #128] 7c: ldr x2, [x19, #8] [...] Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220321152852.2334294-4-xukuohai@huawei.com

With latest upstream llvm18, the following test cases failed: $ ./test_progs -j #13/2 bpf_cookie/multi_kprobe_link_api:FAIL #13/3 bpf_cookie/multi_kprobe_attach_api:FAIL #13 bpf_cookie:FAIL #77 fentry_fexit:FAIL #78/1 fentry_test/fentry:FAIL #78 fentry_test:FAIL #82/1 fexit_test/fexit:FAIL #82 fexit_test:FAIL #112/1 kprobe_multi_test/skel_api:FAIL #112/2 kprobe_multi_test/link_api_addrs:FAIL ... #112 kprobe_multi_test:FAIL #356/17 test_global_funcs/global_func17:FAIL #356 test_global_funcs:FAIL Further analysis shows llvm upstream patch [1] is responsible for the above failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c, without [1], the asm code is: 0000000000000400 <bpf_fentry_test7>: 400: f3 0f 1e fa endbr64 404: e8 00 00 00 00 callq 0x409 <bpf_fentry_test7+0x9> 409: 48 89 f8 movq %rdi, %rax 40c: c3 retq 40d: 0f 1f 00 nopl (%rax) and with [1], the asm code is: 0000000000005d20 <bpf_fentry_test7.specialized.1>: 5d20: e8 00 00 00 00 callq 0x5d25 <bpf_fentry_test7.specialized.1+0x5> 5d25: c3 retq and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7> and this caused test failures for #13/#77 etc. except #356. For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog looks like: 0000000000000000 <global_func17>: 0: b4 00 00 00 2a 00 00 00 w0 = 0x2a 1: 95 00 00 00 00 00 00 00 exit which passed verification while the test itself expects a verification failure. Let us add 'barrier_var' style asm code in both places to prevent function specialization which caused selftests failure. [1] llvm/llvm-project#72903 Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

With latest upstream llvm18, the following test cases failed: $ ./test_progs -j #13/2 bpf_cookie/multi_kprobe_link_api:FAIL #13/3 bpf_cookie/multi_kprobe_attach_api:FAIL #13 bpf_cookie:FAIL #77 fentry_fexit:FAIL #78/1 fentry_test/fentry:FAIL #78 fentry_test:FAIL #82/1 fexit_test/fexit:FAIL #82 fexit_test:FAIL #112/1 kprobe_multi_test/skel_api:FAIL #112/2 kprobe_multi_test/link_api_addrs:FAIL [...] #112 kprobe_multi_test:FAIL #356/17 test_global_funcs/global_func17:FAIL #356 test_global_funcs:FAIL Further analysis shows llvm upstream patch [1] is responsible for the above failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c, without [1], the asm code is: 0000000000000400 <bpf_fentry_test7>: 400: f3 0f 1e fa endbr64 404: e8 00 00 00 00 callq 0x409 <bpf_fentry_test7+0x9> 409: 48 89 f8 movq %rdi, %rax 40c: c3 retq 40d: 0f 1f 00 nopl (%rax) ... and with [1], the asm code is: 0000000000005d20 <bpf_fentry_test7.specialized.1>: 5d20: e8 00 00 00 00 callq 0x5d25 <bpf_fentry_test7.specialized.1+0x5> 5d25: c3 retq ... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7> and this caused test failures for #13/#77 etc. except #356. For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog looks like: 0000000000000000 <global_func17>: 0: b4 00 00 00 2a 00 00 00 w0 = 0x2a 1: 95 00 00 00 00 00 00 00 exit ... which passed verification while the test itself expects a verification failure. Let us add 'barrier_var' style asm code in both places to prevent function specialization which caused selftests failure. [1] llvm/llvm-project#72903 Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231127050342.1945270-1-yonghong.song@linux.dev

If CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable is 0, there exist 6 failed tests. [root@linux bpf]# echo 0 > /proc/sys/net/core/bpf_jit_enable [root@linux bpf]# ./test_verifier | grep FAIL #107/p inline simple bpf_loop call FAIL #108/p don't inline bpf_loop call, flags non-zero FAIL #109/p don't inline bpf_loop call, callback non-constant FAIL #110/p bpf_loop_inline and a dead func FAIL #111/p bpf_loop_inline stack locations for loop vars FAIL #112/p inline bpf_loop call in a big program FAIL Summary: 505 PASSED, 266 SKIPPED, 6 FAILED The test log shows that callbacks are not allowed in non-JITed programs, interpreter doesn't support them yet, thus these tests should be skipped if jit is disabled, just return -ENOTSUPP instead of -EINVAL for pseudo calls in fixup_call_args(). With this patch: [root@linux bpf]# echo 0 > /proc/sys/net/core/bpf_jit_enable [root@linux bpf]# ./test_verifier | grep FAIL Summary: 505 PASSED, 272 SKIPPED, 0 FAILED Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

The Long branch stub in the trampoline implementation[1] provides flexibility to handles short as well as long branch distance to actual trampoline. Whereas, the 8 bytes long dummy_tramp_addr field sitting before long branch stub leads to failure when enabling verifier based seltest for ppc64. The verifier selftests require disassembing the final jited image to get native asm instructions. Later the disassembled instruction sequence is matched against sequence of instructions provided in test-file under __jited() wrapper. The final jited image contains Out-of-line stub and Long branch stub as part of epilogue jitting for a bpf program. The 8 bytes space for dummy_tramp is sandwitched between both above mentioned stubs. These 8 bytes contain memory address of dummy trampoline during trampoline invocation. The disassembler can make sense of bytes corresponding to Out-of-line and Long branch stub, but 8 bytes containing address makes no sense and disassembly fails resulting in failure of verifier selftests. The following code snippet shows the problem with current arrangement made for dummy_tramp_addr. /* Out-of-line stub */ mflr r0 [b|bl] tramp mtlr r0 //only with OOL b bpf_func + 4 /* Long branch stub */ .long <dummy_tramp_addr> <---Invalid bytes sequence, disassembly fails mflr r11 bcl 20,31,$+4 mflr r12 ld r12, -8-SZL(r12) mtctr r12 mtlr r11 //retain ftrace ABI bctr Following is disassembler output for test program binary of size 112 bytes: 0000006010004de800002039f8ff21f981ff21f87000e1fb3000e13b3000e13b2a006038f8ff7ff8 000000397000e1eb800021387843037d2000804ea602087c00000060a603087cbcffff4bc0341d00 000000c0a602687d05009f42a602887df0ff8ce9a603897da603687d2004804e *** Disasm: len:112 pc:0 left:112 00 00 00 60 : nop *** Disasm: len:112 pc:4 left:108 10 00 4d e8 : ld 2, 16(13) *** Disasm: len:112 pc:8 left:104 00 00 20 39 : li 9, 0 *** Disasm: len:112 pc:12 left:100 f8 ff 21 f9 : std 9, -8(1) *** Disasm: len:112 pc:16 left:96 81 ff 21 f8 : stdu 1, -128(1) *** Disasm: len:112 pc:20 left:92 70 00 e1 fb : std 31, 112(1) *** Disasm: len:112 pc:24 left:88 30 00 e1 3b : addi 31, 1, 48 *** Disasm: len:112 pc:28 left:84 30 00 e1 3b : addi 31, 1, 48 *** Disasm: len:112 pc:32 left:80 2a 00 60 38 : li 3, 42 *** Disasm: len:112 pc:36 left:76 f8 ff 7f f8 : std 3, -8(31) *** Disasm: len:112 pc:40 left:72 00 00 00 39 : li 8, 0 *** Disasm: len:112 pc:44 left:68 70 00 e1 eb : ld 31, 112(1) *** Disasm: len:112 pc:48 left:64 80 00 21 38 : addi 1, 1, 128 *** Disasm: len:112 pc:52 left:60 78 43 03 7d : mr 3, 8 *** Disasm: len:112 pc:56 left:56 20 00 80 4e : blr *** Disasm: len:112 pc:60 left:52 a6 02 08 7c : mflr 0 *** Disasm: len:112 pc:64 left:48 00 00 00 60 : nop *** Disasm: len:112 pc:68 left:44 a6 03 08 7c : mtlr 0 *** Disasm: len:112 pc:72 left:40 bc ff ff 4b : b .-68 *** Disasm: len:112 pc:76 left:36 c0 34 1d 00 : disasm_insn:FAIL:74 Can't disasm instruction at offset 76: c0 34 1d 00 00 00 00 c0 a6 02 68 7d 05 00 9f 42 ^ ^ ^ | dummy_tramp_addr | left over bytes | Solution is to move space for dummy_tramp_stub below Long branch stub. It fecilitates uninterrupted disassembling until last 8-bytes. These last bytes can be reduced from overall program length preventing failure in assembly generation. The changes handling length will be part of separate patch. Following is disassembler output for same test program with moved down dummy_tramp_addr: ..... ..... *** Disasm: len:112 pc:68 left:44 a6 03 08 7c : mtlr 0 *** Disasm: len:112 pc:72 left:40 bc ff ff 4b : b .-68 *** Disasm: len:112 pc:76 left:36 a6 02 68 7d : mflr 11 *** Disasm: len:112 pc:80 left:32 05 00 9f 42 : bcl 20, 31, .+4 *** Disasm: len:112 pc:84 left:28 a6 02 88 7d : mflr 12 *** Disasm: len:112 pc:88 left:24 14 00 8c e9 : ld 12, 20(12) *** Disasm: len:112 pc:92 left:20 a6 03 89 7d : mtctr 12 *** Disasm: len:112 pc:96 left:16 a6 03 68 7d : mtlr 11 *** Disasm: len:112 pc:100 left:12 20 04 80 4e : bctr *** Disasm: len:112 pc:104 left:8 c0 34 1d 00 : disasm_insn:FAIL:74 Can't disasm instruction at offset 104: c0 34 1d 00 00 00 00 c0 Disassembly logic can truncate at 104, ignoring last 8 bytes. Selftest relevant to trampolines are passing with this patch in place: kernel-patches#110 fentry_attach_btf_presence:OK kernel-patches#111 fentry_attach_stress:OK kernel-patches#112 fentry_fexit:OK kernel-patches#113/1 fentry_test/fentry:OK kernel-patches#113/2 fentry_test/fentry_many_args:OK kernel-patches#113 fentry_test:OK kernel-patches#114/1 fexit_bpf2bpf/target_no_callees:OK kernel-patches#114/2 fexit_bpf2bpf/target_yes_callees:OK kernel-patches#114/3 fexit_bpf2bpf/func_replace:OK kernel-patches#114/4 fexit_bpf2bpf/func_replace_verify:OK kernel-patches#114/5 fexit_bpf2bpf/func_sockmap_update:OK kernel-patches#114/6 fexit_bpf2bpf/func_replace_return_code:OK kernel-patches#114/7 fexit_bpf2bpf/func_map_prog_compatibility:OK kernel-patches#114/8 fexit_bpf2bpf/func_replace_unreliable:OK kernel-patches#114/9 fexit_bpf2bpf/func_replace_multi:OK kernel-patches#114/10 fexit_bpf2bpf/fmod_ret_freplace:OK kernel-patches#114/11 fexit_bpf2bpf/func_replace_global_func:OK kernel-patches#114/12 fexit_bpf2bpf/fentry_to_cgroup_bpf:OK kernel-patches#114/13 fexit_bpf2bpf/func_replace_progmap:OK kernel-patches#114 fexit_bpf2bpf:OK kernel-patches#115 fexit_sleep:OK kernel-patches#116 fexit_stress:OK kernel-patches#117/1 fexit_test/fexit:OK kernel-patches#117/2 fexit_test/fexit_many_args:OK kernel-patches#117 fexit_test:OK kernel-patches#213 module_fentry_shadow:OK kernel-patches#299/1 recursive_fentry/attach:OK kernel-patches#299/2 recursive_fentry/load:OK kernel-patches#299/3 recursive_fentry/detach:OK kernel-patches#299 recursive_fentry:OK Summary: 10/20 PASSED, 0 SKIPPED, 0 FAILED [1] https://lore.kernel.org/all/20241030070850.1361304-18-hbathini@linux.ibm.com/ Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>

kernel-patches-bot added bpf-next new V6 labels Sep 25, 2020

kernel-patches-bot force-pushed the series/203554=>bpf-next branch from f0b8151 to d690a30 Compare September 25, 2020 21:20

kernel-patches-bot force-pushed the series/203554=>bpf-next branch from d690a30 to f413936 Compare September 26, 2020 00:06

kernel-patches-bot force-pushed the series/203554=>bpf-next branch from f413936 to ce4eb7e Compare September 26, 2020 00:16

kernel-patches-bot added merge-conflict and removed merge-conflict labels Sep 26, 2020

kernel-patches-bot and others added 4 commits September 28, 2020 12:25

adding ci files

f11f55c

selftests/bpf: add raw_tp_test_run

932604f

This test runs test_run for raw_tracepoint program. The test covers ctx input, retval output, and running on correct cpu. Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Song Liu <songliubraving@fb.com>

kernel-patches-bot force-pushed the series/203554=>bpf-next branch from ce4eb7e to 932604f Compare September 28, 2020 19:25

kernel-patches-bot added accepted and removed new labels Sep 28, 2020

kernel-patches-bot closed this Sep 28, 2020

kernel-patches-bot deleted the series/203554=>bpf-next branch September 30, 2020 16:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

enable BPF_PROG_TEST_RUN for raw_tp#112

enable BPF_PROG_TEST_RUN for raw_tp#112
kernel-patches-bot wants to merge 4 commits intobpf-nextfrom
series/203554=>bpf-next

kernel-patches-bot commented Sep 25, 2020

Uh oh!

kernel-patches-bot commented Sep 25, 2020

Uh oh!

kernel-patches-bot commented Sep 25, 2020

Uh oh!

kernel-patches-bot commented Sep 26, 2020

Uh oh!

kernel-patches-bot commented Sep 26, 2020

Uh oh!

kernel-patches-bot commented Sep 26, 2020

Uh oh!

kernel-patches-bot commented Sep 28, 2020

Uh oh!

kernel-patches-bot commented Sep 28, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

kernel-patches-bot commented Sep 25, 2020

Uh oh!

kernel-patches-bot commented Sep 25, 2020

Uh oh!

kernel-patches-bot commented Sep 25, 2020

Uh oh!

kernel-patches-bot commented Sep 26, 2020

Uh oh!

kernel-patches-bot commented Sep 26, 2020

Uh oh!

kernel-patches-bot commented Sep 26, 2020

Uh oh!

kernel-patches-bot commented Sep 28, 2020

Uh oh!

kernel-patches-bot commented Sep 28, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants