bpf: Support new insns from cpu v4 #5377

kernel-patches-daemon-bpf · 2023-07-20T00:09:16Z

Pull request for series with
subject: bpf: Support new insns from cpu v4
version: 3
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=767580

kernel-patches-daemon-bpf · 2023-07-20T00:09:17Z

Upstream branch: 6f5a630
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=767580
version: 3

kernel-patches-daemon-bpf · 2023-07-20T15:10:59Z

Upstream branch: b446934
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=767580
version: 3

kernel-patches-daemon-bpf · 2023-07-24T17:59:46Z

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=767580 expired. Closing PR.

kernel-patches-daemon-bpf · 2023-07-26T22:32:15Z

Upstream branch: 63e2da3
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=769867
version: 4

kernel-patches-daemon-bpf · 2023-07-26T22:38:13Z

Upstream branch: 63e2da3
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=769867
version: 4

kernel-patches-daemon-bpf · 2023-07-28T00:38:57Z

Upstream branch: 10d78a6
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=769867
version: 4

Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=769867
error message:

Cmd('git') failed due to: exit code(128)
  cmdline: git am --3way
  stdout: 'Applying: bpf: Support new sign-extension load insns
Applying: bpf: Support new sign-extension mov insns
Applying: bpf: Handle sign-extenstin ctx member accesses
Applying: bpf: Support new unconditional bswap instruction
Applying: bpf: Support new signed div/mod instructions.
Applying: bpf: Fix jit blinding with new sdiv/smov insns
Applying: bpf: Support new 32bit offset jmp instruction
Applying: selftests/bpf: Fix a test_verifier failure
Applying: selftests/bpf: Add a cpuv4 test runner for cpu=v4 testing
Applying: selftests/bpf: Add unit tests for new sign-extension load insns
Applying: selftests/bpf: Add unit tests for new sign-extension mov insns
Applying: selftests/bpf: Add unit tests for new bswap insns
Applying: selftests/bpf: Add unit tests for new sdiv/smod insns
Applying: selftests/bpf: Add unit tests for new gotol insn
Applying: selftests/bpf: Test ldsx with more complex cases
Applying: docs/bpf: Add documentation for new instructions
Using index info to reconstruct a base tree...
M	Documentation/bpf/standardization/instruction-set.rst
Falling back to patching base and 3-way merge...
Auto-merging Documentation/bpf/standardization/instruction-set.rst
CONFLICT (content): Merge conflict in Documentation/bpf/standardization/instruction-set.rst
Patch failed at 0016 docs/bpf: Add documentation for new instructions
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".'
  stderr: 'error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch'

conflict:

diff --cc Documentation/bpf/standardization/instruction-set.rst
index 6ef5534b410a,f36bee41c719..000000000000
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@@ -154,24 -154,27 +154,48 @@@ otherwise identical operations
  The 'code' field encodes the operation as below, where 'src' and 'dst' refer
  to the values of the source and destination registers, respectively.
  
++<<<<<<< HEAD
 +========  =====  ==========================================================
 +code      value  description
 +========  =====  ==========================================================
 +BPF_ADD   0x00   dst += src
 +BPF_SUB   0x10   dst -= src
 +BPF_MUL   0x20   dst \*= src
 +BPF_DIV   0x30   dst = (src != 0) ? (dst / src) : 0
 +BPF_OR    0x40   dst \|= src
 +BPF_AND   0x50   dst &= src
 +BPF_LSH   0x60   dst <<= (src & mask)
 +BPF_RSH   0x70   dst >>= (src & mask)
 +BPF_NEG   0x80   dst = -dst
 +BPF_MOD   0x90   dst = (src != 0) ? (dst % src) : dst
 +BPF_XOR   0xa0   dst ^= src
 +BPF_MOV   0xb0   dst = src
 +BPF_ARSH  0xc0   sign extending dst >>= (src & mask)
 +BPF_END   0xd0   byte swap operations (see `Byte swap instructions`_ below)
 +========  =====  ==========================================================
++=======
+ ========  =====  =======  ==========================================================
+ code      value  offset   description
+ ========  =====  =======  ==========================================================
+ BPF_ADD   0x00   0        dst += src
+ BPF_SUB   0x10   0        dst -= src
+ BPF_MUL   0x20   0        dst \*= src
+ BPF_DIV   0x30   0        dst = (src != 0) ? (dst / src) : 0
+ BPF_SDIV  0x30   1        dst = (src != 0) ? (dst s/ src) : 0
+ BPF_OR    0x40   0        dst \|= src
+ BPF_AND   0x50   0        dst &= src
+ BPF_LSH   0x60   0        dst <<= (src & mask)
+ BPF_RSH   0x70   0        dst >>= (src & mask)
+ BPF_NEG   0x80   0        dst = -src
+ BPF_MOD   0x90   0        dst = (src != 0) ? (dst % src) : dst
+ BPF_SMOD  0x90   1        dst = (src != 0) ? (dst s% src) : dst
+ BPF_XOR   0xa0   0        dst ^= src
+ BPF_MOV   0xb0   0        dst = src
+ BPF_MOVSX 0xb0   8/16/32  dst = (s8,s16,s32)src
+ BPF_ARSH  0xc0   0        sign extending dst >>= (src & mask)
+ BPF_END   0xd0   0        byte swap operations (see `Byte swap instructions`_ below)
+ ========  =====  ============  ==========================================================
++>>>>>>> docs/bpf: Add documentation for new instructions
  
  Underflow and overflow are allowed during arithmetic operations, meaning
  the 64-bit or 32-bit value will wrap. If eBPF program execution would

Add interpreter/jit support for new sign-extension load insns which adds a new mode (BPF_MEMSX). Also add verifier support to recognize these insns and to do proper verification with new insns. In verifier, besides to deduce proper bounds for the dst_reg, probed memory access is also properly handled. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add interpreter/jit support for new sign-extension mov insns. The original 'MOV' insn is extended to support reg-to-reg signed version for both ALU and ALU64 operations. For ALU mode, the insn->off value of 8 or 16 indicates sign-extension from 8- or 16-bit value to 32-bit value. For ALU64 mode, the insn->off value of 8/16/32 indicates sign-extension from 8-, 16- or 32-bit value to 64-bit value. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Currently, if user accesses a ctx member with signed types, the compiler will generate an unsigned load followed by necessary left and right shifts. With the introduction of sign-extension load, compiler may just emit a ldsx insn instead. Let us do a final movsx sign extension to the final unsigned ctx load result to satisfy original sign extension requirement. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

The existing 'be' and 'le' insns will do conditional bswap depends on host endianness. This patch implements unconditional bswap insns. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add interpreter/jit support for new signed div/mod insns. The new signed div/mod instructions are encoded with unsigned div/mod instructions plus insn->off == 1. Also add basic verifier support to ensure new insns get accepted. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Handle new insns properly in bpf_jit_blind_insn() function. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add interpreter/jit/verifier support for 32bit offset jmp instruction. If a conditional jmp instruction needs more than 16bit offset, it can be simulated with a conditional jmp + a 32bit jmp insn. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

The following test_verifier subtest failed due to new encoding for BSWAP. $ ./test_verifier ... #99/u invalid 64-bit BPF_END FAIL Unexpected success to load! verification time 215 usec stack depth 0 processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 #99/p invalid 64-bit BPF_END FAIL Unexpected success to load! verification time 198 usec stack depth 0 processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 Tighten the test so it still reports a failure. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Similar to no-alu32 runner, if clang compiler supports -mcpu=v4, a cpuv4 runner is created to test bpf programs compiled with -mcpu=v4. The following are some num-of-insn statistics for each newer instructions based on existing selftests, excluding subsequent cpuv4 insn specific tests. insn pattern # of instructions reg = (s8)reg 4 reg = (s16)reg 4 reg = (s32)reg 144 reg = *(s8 *)(reg + off) 13 reg = *(s16 *)(reg + off) 14 reg = *(s32 *)(reg + off) 15215 reg = bswap16 reg 142 reg = bswap32 reg 38 reg = bswap64 reg 14 reg s/= reg 0 reg s%= reg 0 gotol <offset> 58 Note that in llvm -mcpu=v4 implementation, the compiler is a little bit conservative about generating 'gotol' insn (32-bit branch offset) as it didn't precise count the number of insns (e.g., some insns are debug insns, etc.). Compared to old 'goto' insn, newer 'gotol' insn should have comparable verification states to 'goto' insn. With current patch set, all selftests passed with -mcpu=v4 when running test_progs-cpuv4 binary. The -mcpu=v3 and -mcpu=v2 run are also successful. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add unit tests for new ldsx insns. The test includes sign-extension with a single value or with a value range. If cpuv4 is not supported due to (1) older compiler, e.g., less than clang version 18, or (2) test runner test_progs and test_progs-no_alu32 which tests cpu v2 and v3, or (3) non-x86_64 arch not supporting new insns in jit yet, a dummy program is added with below output: #318/1 verifier_ldsx/cpuv4 is not supported by compiler or jit, use a dummy test:OK #318 verifier_ldsx:OK to indicate the test passed with a dummy test instead of actually testing cpuv4. I am using a dummy prog to avoid changing the verifier testing infrastructure. Once clang 18 is widely available and other architectures support cpuv4, at least for CI run, the dummy program can be removed. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add unit tests for movsx insns. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add unit tests for bswap insns. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add unit tests for sdiv/smod insns. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add unit tests for gotol insn. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

kernel-patches-daemon-bpf · 2023-07-28T01:20:56Z

Upstream branch: 10d78a6
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=770346
version: 5

The following ldsx cases are tested: - signed readonly map value - read/write map value - probed memory - not-narrowed ctx field access - narrowed ctx field access. Without previous proper verifier/git handling, the test will fail. If cpuv4 is not supported either by compiler or by jit, the test will be skipped. # ./test_progs -t ldsx_insn #113/1 ldsx_insn/map_val and probed_memory:SKIP #113/2 ldsx_insn/ctx_member_sign_ext:SKIP #113/3 ldsx_insn/ctx_member_narrow_sign_ext:SKIP #113 ldsx_insn:SKIP Summary: 1/0 PASSED, 3 SKIPPED, 0 FAILED Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Add documentation in instruction-set.rst for new instruction encoding and their corresponding operations. Also removed the question related to 'no BPF_SDIV' in bpf_design_QA.rst since we have BPF_SDIV insn now. Cc: bpf@ietf.org Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

kernel-patches-daemon-bpf · 2023-07-28T02:25:10Z

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=770346 irrelevant now. Closing PR.

Verifier log avoids printing the same source code line multiple times when a consecutive block of BPF assembly instructions are covered by the same original (C) source code line. This greatly improves verifier log legibility. Unfortunately, this check is imperfect and in production applications it quite often happens that verifier log will have multiple duplicated source lines emitted, for no apparently good reason. E.g., this is excerpt from a real-world BPF application (with register states omitted for clarity): BEFORE ====== ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5369: (07) r8 += 2 ; 5370: (07) r7 += 16 ; ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5371: (07) r9 += 1 ; 5372: (79) r4 = *(u64 *)(r10 -32) ; ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5373: (55) if r9 != 0xf goto pc+2 ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5376: (79) r1 = *(u64 *)(r10 -40) ; 5377: (79) r1 = *(u64 *)(r1 +8) ; ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5378: (dd) if r1 s<= r9 goto pc-5 ; ; descr->key_lens[i] = 0; @ strobemeta_probe.bpf.c:398 5379: (b4) w1 = 0 ; 5380: (6b) *(u16 *)(r8 -30) = r1 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5381: (79) r3 = *(u64 *)(r7 -8) ; 5382: (7b) *(u64 *)(r10 -24) = r6 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5383: (bc) w6 = w6 ; ; barrier_var(payload_off); @ strobemeta_probe.bpf.c:280 5384: (bf) r2 = r6 ; 5385: (bf) r1 = r4 ; As can be seen, line 394 is emitted thrice, 396 is emitted twice, and line 400 is duplicated as well. Note that there are no intermingling other lines of source code in between these duplicates, so the issue is not compiler reordering assembly instruction such that multiple original source code lines are in effect. It becomes more obvious what's going on if we look at *full* original line info information (using btfdump for this, [0]): #2764: line: insn #5363 --> 394:3 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2765: line: insn #5373 --> 394:21 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2766: line: insn #5375 --> 394:47 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2767: line: insn #5377 --> 394:3 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2768: line: insn #5378 --> 414:10 @ ./././strobemeta_probe.bpf.c return off; We can see that there are four line info records covering instructions #5363 through #5377 (instruction indices are shifted due to subprog instruction being appended to main program), all of them are pointing to the same C source code line #394. But each of them points to a different part of that line, which is denoted by differing column numbers (3, 21, 47, 3). But verifier log doesn't distinguish between parts of the same source code line and doesn't emit this column number information, so for end user it's just a repetitive visual noise. So let's improve the detection of repeated source code line and avoid this. With the changes in this patch, we get this output for the same piece of BPF program log: AFTER ===== ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5369: (07) r8 += 2 ; 5370: (07) r7 += 16 ; 5371: (07) r9 += 1 ; 5372: (79) r4 = *(u64 *)(r10 -32) ; 5373: (55) if r9 != 0xf goto pc+2 ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5376: (79) r1 = *(u64 *)(r10 -40) ; 5377: (79) r1 = *(u64 *)(r1 +8) ; 5378: (dd) if r1 s<= r9 goto pc-5 ; ; descr->key_lens[i] = 0; @ strobemeta_probe.bpf.c:398 5379: (b4) w1 = 0 ; 5380: (6b) *(u16 *)(r8 -30) = r1 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5381: (79) r3 = *(u64 *)(r7 -8) ; 5382: (7b) *(u64 *)(r10 -24) = r6 ; 5383: (bc) w6 = w6 ; ; barrier_var(payload_off); @ strobemeta_probe.bpf.c:280 5384: (bf) r2 = r6 ; 5385: (bf) r1 = r4 ; All the duplication is gone and the log is cleaner and less distracting. [0] https://github.com/anakryiko/btfdump Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Verifier log avoids printing the same source code line multiple times when a consecutive block of BPF assembly instructions are covered by the same original (C) source code line. This greatly improves verifier log legibility. Unfortunately, this check is imperfect and in production applications it quite often happens that verifier log will have multiple duplicated source lines emitted, for no apparently good reason. E.g., this is excerpt from a real-world BPF application (with register states omitted for clarity): BEFORE ====== ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5369: (07) r8 += 2 ; 5370: (07) r7 += 16 ; ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5371: (07) r9 += 1 ; 5372: (79) r4 = *(u64 *)(r10 -32) ; ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5373: (55) if r9 != 0xf goto pc+2 ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5376: (79) r1 = *(u64 *)(r10 -40) ; 5377: (79) r1 = *(u64 *)(r1 +8) ; ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5378: (dd) if r1 s<= r9 goto pc-5 ; ; descr->key_lens[i] = 0; @ strobemeta_probe.bpf.c:398 5379: (b4) w1 = 0 ; 5380: (6b) *(u16 *)(r8 -30) = r1 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5381: (79) r3 = *(u64 *)(r7 -8) ; 5382: (7b) *(u64 *)(r10 -24) = r6 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5383: (bc) w6 = w6 ; ; barrier_var(payload_off); @ strobemeta_probe.bpf.c:280 5384: (bf) r2 = r6 ; 5385: (bf) r1 = r4 ; As can be seen, line 394 is emitted thrice, 396 is emitted twice, and line 400 is duplicated as well. Note that there are no intermingling other lines of source code in between these duplicates, so the issue is not compiler reordering assembly instruction such that multiple original source code lines are in effect. It becomes more obvious what's going on if we look at *full* original line info information (using btfdump for this, [0]): #2764: line: insn #5363 --> 394:3 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2765: line: insn #5373 --> 394:21 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2766: line: insn #5375 --> 394:47 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2767: line: insn #5377 --> 394:3 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2768: line: insn #5378 --> 414:10 @ ./././strobemeta_probe.bpf.c return off; We can see that there are four line info records covering instructions #5363 through #5377 (instruction indices are shifted due to subprog instruction being appended to main program), all of them are pointing to the same C source code line #394. But each of them points to a different part of that line, which is denoted by differing column numbers (3, 21, 47, 3). But verifier log doesn't distinguish between parts of the same source code line and doesn't emit this column number information, so for end user it's just a repetitive visual noise. So let's improve the detection of repeated source code line and avoid this. With the changes in this patch, we get this output for the same piece of BPF program log: AFTER ===== ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5369: (07) r8 += 2 ; 5370: (07) r7 += 16 ; 5371: (07) r9 += 1 ; 5372: (79) r4 = *(u64 *)(r10 -32) ; 5373: (55) if r9 != 0xf goto pc+2 ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5376: (79) r1 = *(u64 *)(r10 -40) ; 5377: (79) r1 = *(u64 *)(r1 +8) ; 5378: (dd) if r1 s<= r9 goto pc-5 ; ; descr->key_lens[i] = 0; @ strobemeta_probe.bpf.c:398 5379: (b4) w1 = 0 ; 5380: (6b) *(u16 *)(r8 -30) = r1 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5381: (79) r3 = *(u64 *)(r7 -8) ; 5382: (7b) *(u64 *)(r10 -24) = r6 ; 5383: (bc) w6 = w6 ; ; barrier_var(payload_off); @ strobemeta_probe.bpf.c:280 5384: (bf) r2 = r6 ; 5385: (bf) r1 = r4 ; All the duplication is gone and the log is cleaner and less distracting. [0] https://github.com/anakryiko/btfdump Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20240214174100.2847419-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>

kernel-patches-daemon-bpf bot added new bpf-next V3 labels Jul 20, 2023

kernel-patches-daemon-bpf bot force-pushed the bpf-next_base branch from 7073834 to 390d4c3 Compare July 20, 2023 15:09

kernel-patches-daemon-bpf bot force-pushed the series/761123=>bpf-next branch from e0a242b to 72d11eb Compare July 20, 2023 15:11

kernel-patches-daemon-bpf bot added changes-requested and removed new labels Jul 24, 2023

kernel-patches-daemon-bpf bot closed this Jul 24, 2023

kernel-patches-daemon-bpf bot reopened this Jul 26, 2023

kernel-patches-daemon-bpf bot added new V4 and removed changes-requested V3 labels Jul 26, 2023

kernel-patches-daemon-bpf bot force-pushed the series/761123=>bpf-next branch from 72d11eb to 2360bde Compare July 26, 2023 22:32

kernel-patches-daemon-bpf bot force-pushed the series/761123=>bpf-next branch from 2360bde to 9d7cd12 Compare July 26, 2023 22:38

adding ci files

87478e7

kernel-patches-daemon-bpf bot force-pushed the bpf-next_base branch from a33d978 to 87478e7 Compare July 28, 2023 00:38

kernel-patches-daemon-bpf bot added the merge-conflict label Jul 28, 2023

Yonghong Song added 6 commits July 27, 2023 18:20

bpf: Support new unconditional bswap instruction

569a4eb

The existing 'be' and 'le' insns will do conditional bswap depends on host endianness. This patch implements unconditional bswap insns. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

bpf: Fix jit blinding with new sdiv/smov insns

892f7e2

Handle new insns properly in bpf_jit_blind_insn() function. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Yonghong Song added 8 commits July 27, 2023 18:20

selftests/bpf: Add unit tests for new sign-extension mov insns

e1bd491

Add unit tests for movsx insns. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

selftests/bpf: Add unit tests for new bswap insns

6e5a383

Add unit tests for bswap insns. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

selftests/bpf: Add unit tests for new sdiv/smod insns

1bbd742

Add unit tests for sdiv/smod insns. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

selftests/bpf: Add unit tests for new gotol insn

1f524dc

Add unit tests for gotol insn. Signed-off-by: Yonghong Song <yonghong.song@linux.dev>

Yonghong Song added 2 commits July 27, 2023 18:20

kernel-patches-daemon-bpf bot added V5 and removed merge-conflict V4 labels Jul 28, 2023

kernel-patches-daemon-bpf bot force-pushed the series/761123=>bpf-next branch from 9d7cd12 to 77c5a08 Compare July 28, 2023 01:21

kernel-patches-daemon-bpf bot force-pushed the bpf-next_base branch from 87478e7 to 72c000e Compare July 28, 2023 02:21

kernel-patches-daemon-bpf bot added accepted and removed new labels Jul 28, 2023

kernel-patches-daemon-bpf bot closed this Jul 28, 2023

kernel-patches-daemon-bpf bot deleted the series/761123=>bpf-next branch July 28, 2023 02:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

bpf: Support new insns from cpu v4 #5377

bpf: Support new insns from cpu v4 #5377

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 20, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 20, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 20, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 24, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 26, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 26, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 28, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 28, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 28, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

bpf: Support new insns from cpu v4 #5377

bpf: Support new insns from cpu v4 #5377

Uh oh!

Conversation

kernel-patches-daemon-bpf bot commented Jul 20, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 20, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 20, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 24, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 26, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 26, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 28, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 28, 2023

Uh oh!

kernel-patches-daemon-bpf bot commented Jul 28, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant