Files
linux/include/uapi/linux
Peilin Ye 880442305a bpf: Introduce load-acquire and store-release instructions
Introduce BPF instructions with load-acquire and store-release
semantics, as discussed in [1].  Define 2 new flags:

  #define BPF_LOAD_ACQ    0x100
  #define BPF_STORE_REL   0x110

A "load-acquire" is a BPF_STX | BPF_ATOMIC instruction with the 'imm'
field set to BPF_LOAD_ACQ (0x100).

Similarly, a "store-release" is a BPF_STX | BPF_ATOMIC instruction with
the 'imm' field set to BPF_STORE_REL (0x110).

Unlike existing atomic read-modify-write operations that only support
BPF_W (32-bit) and BPF_DW (64-bit) size modifiers, load-acquires and
store-releases also support BPF_B (8-bit) and BPF_H (16-bit).  As an
exception, however, 64-bit load-acquires/store-releases are not
supported on 32-bit architectures (to fix a build error reported by the
kernel test robot).

An 8- or 16-bit load-acquire zero-extends the value before writing it to
a 32-bit register, just like ARM64 instruction LDARH and friends.

Similar to existing atomic read-modify-write operations, misaligned
load-acquires/store-releases are not allowed (even if
BPF_F_ANY_ALIGNMENT is set).

As an example, consider the following 64-bit load-acquire BPF
instruction (assuming little-endian):

  db 10 00 00 00 01 00 00  r0 = load_acquire((u64 *)(r1 + 0x0))

  opcode (0xdb): BPF_ATOMIC | BPF_DW | BPF_STX
  imm (0x00000100): BPF_LOAD_ACQ

Similarly, a 16-bit BPF store-release:

  cb 21 00 00 10 01 00 00  store_release((u16 *)(r1 + 0x0), w2)

  opcode (0xcb): BPF_ATOMIC | BPF_H | BPF_STX
  imm (0x00000110): BPF_STORE_REL

In arch/{arm64,s390,x86}/net/bpf_jit_comp.c, have
bpf_jit_supports_insn(..., /*in_arena=*/true) return false for the new
instructions, until the corresponding JIT compiler supports them in
arena.

[1] https://lore.kernel.org/all/20240729183246.4110549-1-yepeilin@google.com/

Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: kernel test robot <lkp@intel.com>
Signed-off-by: Peilin Ye <yepeilin@google.com>
Link: https://lore.kernel.org/r/a217f46f0e445fbd573a1a024be5c6bf1d5fe716.1741049567.git.yepeilin@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-03-15 11:48:28 -07:00
..
2024-07-31 13:56:00 +02:00
2024-04-15 13:42:38 +02:00
2024-11-03 20:33:43 +00:00
2025-01-13 07:36:29 -08:00
2024-12-04 16:08:34 +01:00
2021-11-01 13:36:08 +00:00
2022-08-11 10:31:19 -07:00
2024-08-28 06:53:58 -07:00
2021-11-26 16:48:59 +01:00
2024-08-28 06:53:58 -07:00
2023-01-20 09:33:22 +00:00
2024-04-08 14:10:45 +01:00
2024-06-11 12:57:49 -05:00
2025-01-17 22:23:47 +01:00
2024-11-01 01:19:00 +00:00
2023-03-16 21:20:32 -07:00
2023-09-21 19:22:05 +02:00
2022-08-10 13:49:50 +01:00
2024-05-07 01:35:57 +02:00
2024-08-29 10:39:37 +02:00
2021-11-15 07:53:10 -08:00
2021-06-03 15:31:34 -07:00
2024-04-01 10:49:28 +01:00
2024-08-26 09:37:23 -07:00
2024-06-01 07:28:21 +02:00
2024-09-01 20:26:05 -07:00
2022-09-20 09:13:38 +02:00
2024-09-16 23:50:52 +02:00
2024-08-19 22:36:26 -04:00
2021-03-10 09:34:06 +01:00
2023-12-15 17:01:30 +01:00
2024-09-06 08:31:40 -06:00
2022-09-07 16:46:03 +02:00
2024-08-12 17:50:34 -07:00
2023-11-28 19:05:16 +00:00
2025-01-08 13:18:11 +01:00
2025-01-23 13:05:06 -06:00
2024-10-24 13:54:51 +02:00
2023-12-20 19:26:31 -05:00
2025-01-09 16:23:17 +01:00
2022-11-17 11:04:23 -08:00
2022-09-27 17:29:09 -07:00
2024-10-09 19:55:40 -07:00
2023-12-29 11:58:24 -08:00
2023-03-23 17:25:46 +01:00
2024-11-05 10:24:16 +00:00
2021-06-12 13:16:45 -07:00