[PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[Alexis Lothoré (eBPF Foundation)]

Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic
instructions modifiers. Those are currently not described in the
documentation, despite being used in the verifier and the various JIT
compilers supporting them.

Add the missing entries in the instruction set documentation.

Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
Changes in v2:
- fix commit message typo
- clarify zero-extension and registers meaning for LOAD_ACQ
- clarify insn encoding for LOAD_ACQ and STORE_REL
- Link to v1: https://patch.msgid.link/20260520-bpf-insn-doc-v1-1-74d7dada9bfc@bootlin.com

To: David Vernet <void@manifault.com>
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii@kernel.org>
To: Martin KaFai Lau <martin.lau@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Song Liu <song@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <jolsa@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: ebpf@linuxfoundation.org
Cc: Bastien Curutchet <bastien.curutchet@bootlin.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: bpf@vger.kernel.org
Cc: bpf@ietf.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 .../bpf/standardization/instruction-set.rst        | 27 +++++++++++++++-------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index 39c74611752b..e8b33374bd09 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -668,7 +668,8 @@ that use the ``ATOMIC`` mode modifier as follows:
   part of the "atomic32" conformance group.
 * ``{ATOMIC, DW, STX}`` for 64-bit operations, which are
   part of the "atomic64" conformance group.
-* 8-bit and 16-bit wide atomic operations are not supported.
+* ``{ATOMIC, H, STX}`` (only for LOAD_ACQ/STORE_REL)
+* ``{ATOMIC, B, STX}`` (only for LOAD_ACQ/STORE_REL)
 
 The 'imm' field is used to encode the actual atomic operation.
 Simple atomic operation use a subset of the values defined to encode
@@ -695,22 +696,24 @@ arithmetic operations in the 'imm' field to encode the atomic operation:
   *(u64 *)(dst + offset) += src
 
 In addition to the simple atomic operations, there also is a modifier and
-two complex atomic operations:
+four complex atomic operations:
 
 .. table:: Complex atomic operations
 
   ===========  ================  ===========================
   imm          value             description
   ===========  ================  ===========================
-  FETCH        0x01              modifier: return old value
-  XCHG         0xe0 | FETCH      atomic exchange
-  CMPXCHG      0xf0 | FETCH      atomic compare and exchange
+  FETCH        0x0001            modifier: return old value
+  XCHG         0x00e0 | FETCH    atomic exchange
+  CMPXCHG      0x00f0 | FETCH    atomic compare and exchange
+  LOAD_ACQ     0x0100            atomic load with barrier
+  STORE_REL    0x0110            atomic store with barrier
   ===========  ================  ===========================
 
 The ``FETCH`` modifier is optional for simple atomic operations, and
-always set for the complex atomic operations.  If the ``FETCH`` flag
-is set, then the operation also overwrites ``src`` with the value that
-was in memory before it was modified.
+always set for the ``XCHG`` and ``CMPXCHG`` complex atomic operations.  If
+the ``FETCH`` flag is set, then the operation also overwrites ``src`` with
+the value that was in memory before it was modified.
 
 The ``XCHG`` operation atomically exchanges ``src`` with the value
 addressed by ``dst + offset``.
@@ -721,6 +724,14 @@ The ``CMPXCHG`` operation atomically compares the value addressed by
 value that was at ``dst + offset`` before the operation is zero-extended
 and loaded back to ``R0``.
 
+The ``LOAD_ACQ`` and ``STORE_REL`` operations allow using lighter load and
+store memory barriers rather than full barriers. The corresponding accesses
+must be aligned, but are allowed for any access size (8-bit up to 64-bit
+operations), with 8-bit and 16-bit ``LOAD_ACQ`` loaded values being
+zero-extended. As atomics are encoded as stores, the meaning of dst and src
+are different for ``LOAD_ACQ``, effectively using src as memory based
+pointer and dst as destination register for the fetched value.
+
 64-bit immediate instructions
 -----------------------------
 

---
base-commit: ceeb3aa37bff895116944acf4347fcded0b7692d
change-id: 20260520-bpf-insn-doc-756b369ca328

Best regards,
--  
Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

[Bpf] [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[Alexis Lothoré (eBPF Foundation)]

Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic
instructions modifiers. Those are currently not described in the
documentation, despite being used in the verifier and the various JIT
compilers supporting them.

Add the missing entries in the instruction set documentation.

Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
Changes in v2:
- fix commit message typo
- clarify zero-extension and registers meaning for LOAD_ACQ
- clarify insn encoding for LOAD_ACQ and STORE_REL
- Link to v1: https://patch.msgid.link/20260520-bpf-insn-doc-v1-1-74d7dada9bfc@bootlin.com

To: David Vernet <void@manifault.com>
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii@kernel.org>
To: Martin KaFai Lau <martin.lau@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Song Liu <song@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <jolsa@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: ebpf@linuxfoundation.org
Cc: Bastien Curutchet <bastien.curutchet@bootlin.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: bpf@vger.kernel.org
Cc: bpf@ietf.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 .../bpf/standardization/instruction-set.rst        | 27 +++++++++++++++-------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index 39c74611752b..e8b33374bd09 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -668,7 +668,8 @@ that use the ``ATOMIC`` mode modifier as follows:
   part of the "atomic32" conformance group.
 * ``{ATOMIC, DW, STX}`` for 64-bit operations, which are
   part of the "atomic64" conformance group.
-* 8-bit and 16-bit wide atomic operations are not supported.
+* ``{ATOMIC, H, STX}`` (only for LOAD_ACQ/STORE_REL)
+* ``{ATOMIC, B, STX}`` (only for LOAD_ACQ/STORE_REL)
 
 The 'imm' field is used to encode the actual atomic operation.
 Simple atomic operation use a subset of the values defined to encode
@@ -695,22 +696,24 @@ arithmetic operations in the 'imm' field to encode the atomic operation:
   *(u64 *)(dst + offset) += src
 
 In addition to the simple atomic operations, there also is a modifier and
-two complex atomic operations:
+four complex atomic operations:
 
 .. table:: Complex atomic operations
 
   ===========  ================  ===========================
   imm          value             description
   ===========  ================  ===========================
-  FETCH        0x01              modifier: return old value
-  XCHG         0xe0 | FETCH      atomic exchange
-  CMPXCHG      0xf0 | FETCH      atomic compare and exchange
+  FETCH        0x0001            modifier: return old value
+  XCHG         0x00e0 | FETCH    atomic exchange
+  CMPXCHG      0x00f0 | FETCH    atomic compare and exchange
+  LOAD_ACQ     0x0100            atomic load with barrier
+  STORE_REL    0x0110            atomic store with barrier
   ===========  ================  ===========================
 
 The ``FETCH`` modifier is optional for simple atomic operations, and
-always set for the complex atomic operations.  If the ``FETCH`` flag
-is set, then the operation also overwrites ``src`` with the value that
-was in memory before it was modified.
+always set for the ``XCHG`` and ``CMPXCHG`` complex atomic operations.  If
+the ``FETCH`` flag is set, then the operation also overwrites ``src`` with
+the value that was in memory before it was modified.
 
 The ``XCHG`` operation atomically exchanges ``src`` with the value
 addressed by ``dst + offset``.
@@ -721,6 +724,14 @@ The ``CMPXCHG`` operation atomically compares the value addressed by
 value that was at ``dst + offset`` before the operation is zero-extended
 and loaded back to ``R0``.
 
+The ``LOAD_ACQ`` and ``STORE_REL`` operations allow using lighter load and
+store memory barriers rather than full barriers. The corresponding accesses
+must be aligned, but are allowed for any access size (8-bit up to 64-bit
+operations), with 8-bit and 16-bit ``LOAD_ACQ`` loaded values being
+zero-extended. As atomics are encoded as stores, the meaning of dst and src
+are different for ``LOAD_ACQ``, effectively using src as memory based
+pointer and dst as destination register for the fetched value.
+
 64-bit immediate instructions
 -----------------------------
 

---
base-commit: ceeb3aa37bff895116944acf4347fcded0b7692d
change-id: 20260520-bpf-insn-doc-756b369ca328

Best regards,
--  
Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

Re: [Bpf] [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The newly added 8-bit (BPF_B) and 16-bit (BPF_H) atomic instructions are not assigned to any conformance group.
- [Medium] The documentation fails to specify that 32-bit LOAD_ACQ operations zero-extend the loaded value into the 64-bit destination register.
- [Low] Commit message typo: 'instroduced' instead of 'introduced'.
- [Low] Subject-verb agreement mismatch in documentation addition.
--

commit 0d39d0f059fd9242ec286f0067c48e70de5d5dc6
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

This commit updates the BPF standardization documentation to include the
LOAD_ACQUIRE and STORE_RELEASE atomic instructions. It adds the missing
entries for these instruction modifiers and describes their behavior.

> bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions
>
> Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
> instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic

[Severity: Low]
This isn't a bug, but there is a typo (instroduced) in the commit message.

> instructions modifiers. Those are currently not described in the
> documentation, despite being used in the verifier and the various JIT
> compilers supporting them.

[ ... ]

> diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
> index 39c74611752b6..e8b33374bd090 100644
> --- a/Documentation/bpf/standardization/instruction-set.rst
> +++ b/Documentation/bpf/standardization/instruction-set.rst
> @@ -668,7 +668,8 @@ that use the ``ATOMIC`` mode modifier as follows:
>    part of the "atomic32" conformance group.
>  * ``{ATOMIC, DW, STX}`` for 64-bit operations, which are
>    part of the "atomic64" conformance group.
> -* 8-bit and 16-bit wide atomic operations are not supported.
> +* ``{ATOMIC, H, STX}`` (only for LOAD_ACQ/STORE_REL)
> +* ``{ATOMIC, B, STX}`` (only for LOAD_ACQ/STORE_REL)

[Severity: Medium]
Do these new 8-bit and 16-bit instructions need to be assigned to a
conformance group?

The BPF instruction set specifies that instructions not explicitly assigned
to a conformance group fall into the base32 group. 

By not adding these to atomic32, atomic64, or a new group, does this implicitly
force minimal BPF runtimes to support 8-bit and 16-bit atomic load/store
operations even if they don't support atomic32 or atomic64?

[ ... ]

> @@ -721,6 +724,14 @@ The ``CMPXCHG`` operation atomically compares the value addressed by
>  value that was at ``dst + offset`` before the operation is zero-extended
>  and loaded back to ``R0``.
>  
> +The ``LOAD_ACQ`` and ``STORE_REL`` operations allow using lighter load and
> +store memory barriers rather than full barriers. The corresponding accesses
> +must be aligned, but are allowed for any access size (8-bit up to 64-bit
> +operations), with 8-bit and 16-bit ``LOAD_ACQ`` loaded values being
> +zero-extended.

[Severity: Medium]
Should the documentation also specify that 32-bit LOAD_ACQ operations are
zero-extended into the 64-bit destination register?

Because LOAD_ACQ is encoded as an atomic store (BPF_STX) rather than a memory
load (BPF_LDX) or an ALU32 operation, it does not strictly inherit the general
zero-extension rules. 

Omitting the 32-bit behavior while explicitly calling out 8-bit and 16-bit
could create an ambiguity that leads to divergent JIT implementations.

> +zero-extended. As atomics are encoded as stores, the meaning of dst and src

[Severity: Low]
This isn't a bug, but there is a subject-verb agreement mismatch here.
"meaning" is singular but "are" is plural. Could this be updated to
"the meanings of dst and src are different" or "the meaning of dst and
src is different"?

> +are different for ``LOAD_ACQ``, effectively using src as memory based
> +pointer and dst as destination register for the fetched value.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520220911.CFvlnyVcHmbbf-7TW9sOJLUFR5zWx_ZUaYCOvpNAHpc@z?part=1

Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The newly added 8-bit and 16-bit atomic instructions lack an explicit conformance group assignment.
- [Medium] The documentation omits the use of the `offset` field for LOAD_ACQ address calculation and lacks explicit pseudo-code for both instructions.
- [Low] The documentation explicitly states that 8-bit and 16-bit LOAD_ACQ values are zero-extended, creating an ambiguity regarding 32-bit values.
--

commit 442218b588f0cff62adb7ca3a7b372a864af4450
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

This commit updates the BPF instruction set documentation to include the
LOAD_ACQUIRE and STORE_RELEASE atomic instruction modifiers. It adds the
missing entries for these instructions, including 8-bit and 16-bit widths,
and explains their complex atomic encoding.

> diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
> index 39c74611752b6..e8b33374bd090 100644
> --- a/Documentation/bpf/standardization/instruction-set.rst
> +++ b/Documentation/bpf/standardization/instruction-set.rst
> @@ -668,7 +668,8 @@ that use the ``ATOMIC`` mode modifier as follows:
>    part of the "atomic32" conformance group.
>  * ``{ATOMIC, DW, STX}`` for 64-bit operations, which are
>    part of the "atomic64" conformance group.
> -* 8-bit and 16-bit wide atomic operations are not supported.
> +* ``{ATOMIC, H, STX}`` (only for LOAD_ACQ/STORE_REL)
> +* ``{ATOMIC, B, STX}`` (only for LOAD_ACQ/STORE_REL)

[Severity: Medium]
Since unassigned instructions default to the base32 conformance group, does
this inadvertently make these 8-bit and 16-bit instructions mandatory for all
implementations?

Should these be assigned to the atomic32, atomic64, or a new conformance group
to avoid imposing this requirement on runtimes that may not support them?

[ ... ]

> @@ -721,6 +724,14 @@ The ``CMPXCHG`` operation atomically compares the value addressed by
>  value that was at ``dst + offset`` before the operation is zero-extended
>  and loaded back to ``R0``.
>  
> +The ``LOAD_ACQ`` and ``STORE_REL`` operations allow using lighter load and
> +store memory barriers rather than full barriers. The corresponding accesses
> +must be aligned, but are allowed for any access size (8-bit up to 64-bit
> +operations), with 8-bit and 16-bit ``LOAD_ACQ`` loaded values being
> +zero-extended. As atomics are encoded as stores, the meaning of dst and src

[Severity: Low]
Does explicitly singling out 8-bit and 16-bit sizes for zero-extension create
ambiguity for 32-bit operations?

While 32-bit operations writing to a register zero-extend to 64 bits by default,
readers might assume 32-bit LOAD_ACQ values require different handling if only
the smaller widths are explicitly mentioned.

> +are different for ``LOAD_ACQ``, effectively using src as memory based
> +pointer and dst as destination register for the fetched value.

[Severity: Medium]
Does the LOAD_ACQ instruction also use the offset field for the address
calculation?

The text states it uses src as the memory pointer, but omits the offset field.
Other atomic operations explicitly use dst + offset.

Would it also be clearer to provide explicit pseudo-code definitions for both
LOAD_ACQ and STORE_REL (e.g., dst = load_acquire((size *)(src + offset))) to
remove ambiguity for JIT compiler and emulator implementers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-bpf-insn-doc-v2-1-8c43c037d599@bootlin.com?part=1

Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

On Thu, May 21, 2026 at 12:09:11AM +0200, Alexis Lothoré (eBPF Foundation) wrote:

Hi Alexis,

Thanks for working on this.

> Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
> instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic

introduced

> instructions modifiers. Those are currently not described in the
> documentation, despite being used in the verifier and the various JIT
> compilers supporting them.
> 
> Add the missing entries in the instruction set documentation.
> 
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

Alexei et al -- if you plan to do a subsequent RFC, it will influence
how this document needs to be structured. [0] explains the process for
adding new instructions. To quote:

> Once a conformance group is registered with a set of instructions, no
> further instructions can be added to that conformance group. A
> specification should instead create a new conformance group that
> includes the original conformance group, plus any newly added
> instructions. Inclusion of the original conformance group is done via
> the "includes" column of the BPF Instruction Conformance Groups
> registry, and inclusion of newly added instructions is done via the
> "groups" column of the BPF Instruction Set registry.

So you would have to create a new conformance group for these new
atomics -- you can't just add them to the existing one. In general it
might be easier / advised to snapshot this file to RFC 9669 and create a
new one for the new instructions to make it easier to tease this stuff
apart later. If that's something you want, I'm happy to get us started
with a skeleton file. Again, though, that's only necessary if you plan
to submit a new document to the IETF WG.

[0]: https://www.rfc-editor.org/rfc/rfc9669.html#name-adding-instructions

[...]

> +The ``LOAD_ACQ`` and ``STORE_REL`` operations allow using lighter load and
> +store memory barriers rather than full barriers. The corresponding accesses
> +must be aligned, but are allowed for any access size (8-bit up to 64-bit
> +operations), with 8-bit and 16-bit ``LOAD_ACQ`` loaded values being
> +zero-extended. As atomics are encoded as stores, the meaning of dst and src

Nit:

``dst`` and ``src``

``src`` below as well.

Note though that as mentioned above, these instructions should probably
go into a new conformance group that includes the existing atomics.

> +are different for ``LOAD_ACQ``, effectively using src as memory based
> +pointer and dst as destination register for the fetched value.
> +
>  64-bit immediate instructions
>  -----------------------------
>  
> 
> ---
> base-commit: ceeb3aa37bff895116944acf4347fcded0b7692d
> change-id: 20260520-bpf-insn-doc-756b369ca328
> 
> Best regards,
> --  
> Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[Bpf] Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 2920 bytes --]

On Thu, May 21, 2026 at 12:09:11AM +0200, Alexis Lothoré (eBPF Foundation) wrote:

Hi Alexis,

Thanks for working on this.

> Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
> instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic

introduced

> instructions modifiers. Those are currently not described in the
> documentation, despite being used in the verifier and the various JIT
> compilers supporting them.
> 
> Add the missing entries in the instruction set documentation.
> 
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>

Alexei et al -- if you plan to do a subsequent RFC, it will influence
how this document needs to be structured. [0] explains the process for
adding new instructions. To quote:

> Once a conformance group is registered with a set of instructions, no
> further instructions can be added to that conformance group. A
> specification should instead create a new conformance group that
> includes the original conformance group, plus any newly added
> instructions. Inclusion of the original conformance group is done via
> the "includes" column of the BPF Instruction Conformance Groups
> registry, and inclusion of newly added instructions is done via the
> "groups" column of the BPF Instruction Set registry.

So you would have to create a new conformance group for these new
atomics -- you can't just add them to the existing one. In general it
might be easier / advised to snapshot this file to RFC 9669 and create a
new one for the new instructions to make it easier to tease this stuff
apart later. If that's something you want, I'm happy to get us started
with a skeleton file. Again, though, that's only necessary if you plan
to submit a new document to the IETF WG.

[0]: https://www.rfc-editor.org/rfc/rfc9669.html#name-adding-instructions

[...]

> +The ``LOAD_ACQ`` and ``STORE_REL`` operations allow using lighter load and
> +store memory barriers rather than full barriers. The corresponding accesses
> +must be aligned, but are allowed for any access size (8-bit up to 64-bit
> +operations), with 8-bit and 16-bit ``LOAD_ACQ`` loaded values being
> +zero-extended. As atomics are encoded as stores, the meaning of dst and src

Nit:

``dst`` and ``src``

``src`` below as well.

Note though that as mentioned above, these instructions should probably
go into a new conformance group that includes the existing atomics.

> +are different for ``LOAD_ACQ``, effectively using src as memory based
> +pointer and dst as destination register for the fetched value.
> +
>  64-bit immediate instructions
>  -----------------------------
>  
> 
> ---
> base-commit: ceeb3aa37bff895116944acf4347fcded0b7692d
> change-id: 20260520-bpf-insn-doc-756b369ca328
> 
> Best regards,
> --  
> Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 88 bytes --]

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[Alexis Lothoré]

Hi David,

On Thu May 21, 2026 at 4:17 AM CEST, David Vernet wrote:
> On Thu, May 21, 2026 at 12:09:11AM +0200, Alexis Lothoré (eBPF Foundation) wrote:
>
> Hi Alexis,
>
> Thanks for working on this.
>
>> Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
>> instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic
>
> introduced
>
>> instructions modifiers. Those are currently not described in the
>> documentation, despite being used in the verifier and the various JIT
>> compilers supporting them.
>> 
>> Add the missing entries in the instruction set documentation.
>> 
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>
> Alexei et al -- if you plan to do a subsequent RFC, it will influence
> how this document needs to be structured. [0] explains the process for
> adding new instructions. To quote:
>
>> Once a conformance group is registered with a set of instructions, no
>> further instructions can be added to that conformance group. A
>> specification should instead create a new conformance group that
>> includes the original conformance group, plus any newly added
>> instructions. Inclusion of the original conformance group is done via
>> the "includes" column of the BPF Instruction Conformance Groups
>> registry, and inclusion of newly added instructions is done via the
>> "groups" column of the BPF Instruction Set registry.
>
> So you would have to create a new conformance group for these new
> atomics -- you can't just add them to the existing one. In general it
> might be easier / advised to snapshot this file to RFC 9669 and create a
> new one for the new instructions to make it easier to tease this stuff
> apart later. If that's something you want, I'm happy to get us started
> with a skeleton file. Again, though, that's only necessary if you plan
> to submit a new document to the IETF WG.
>
> [0]: https://www.rfc-editor.org/rfc/rfc9669.html#name-adding-instructions

I don't know how heavy/long the process is to submit this kind of RFC
update, but your point makes it sound like it makes more sense to just
go directly for the proper way, ie adding the conformance group and then
adding those new ops in there, rather than updating the kernel doc as my
series is proposing, and then later reverting to a proper conformance
group.

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Bpf] Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[Alexis Lothoré]

Hi David,

On Thu May 21, 2026 at 4:17 AM CEST, David Vernet wrote:
> On Thu, May 21, 2026 at 12:09:11AM +0200, Alexis Lothoré (eBPF Foundation) wrote:
>
> Hi Alexis,
>
> Thanks for working on this.
>
>> Commit 880442305a39 ("bpf: Introduce load-acquire and store-release
>> instructions") instroduced the LOAD_ACQUIRE and STORE_RELEASE atomic
>
> introduced
>
>> instructions modifiers. Those are currently not described in the
>> documentation, despite being used in the verifier and the various JIT
>> compilers supporting them.
>> 
>> Add the missing entries in the instruction set documentation.
>> 
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>
> Alexei et al -- if you plan to do a subsequent RFC, it will influence
> how this document needs to be structured. [0] explains the process for
> adding new instructions. To quote:
>
>> Once a conformance group is registered with a set of instructions, no
>> further instructions can be added to that conformance group. A
>> specification should instead create a new conformance group that
>> includes the original conformance group, plus any newly added
>> instructions. Inclusion of the original conformance group is done via
>> the "includes" column of the BPF Instruction Conformance Groups
>> registry, and inclusion of newly added instructions is done via the
>> "groups" column of the BPF Instruction Set registry.
>
> So you would have to create a new conformance group for these new
> atomics -- you can't just add them to the existing one. In general it
> might be easier / advised to snapshot this file to RFC 9669 and create a
> new one for the new instructions to make it easier to tease this stuff
> apart later. If that's something you want, I'm happy to get us started
> with a skeleton file. Again, though, that's only necessary if you plan
> to submit a new document to the IETF WG.
>
> [0]: https://www.rfc-editor.org/rfc/rfc9669.html#name-adding-instructions

I don't know how heavy/long the process is to submit this kind of RFC
update, but your point makes it sound like it makes more sense to just
go directly for the proper way, ie adding the conformance group and then
adding those new ops in there, rather than updating the kernel doc as my
series is proposing, and then later reverting to a proper conformance
group.

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Fri, May 22, 2026 at 10:35:20AM +0200, Alexis Lothoré wrote:

[...]

> I don't know how heavy/long the process is to submit this kind of RFC
> update, but your point makes it sound like it makes more sense to just
> go directly for the proper way, ie adding the conformance group and then
> adding those new ops in there, rather than updating the kernel doc as my
> series is proposing, and then later reverting to a proper conformance
> group.

Hey Alexis,

Apologies for the delay. My email filter was broken so I only just saw
this. Yes, this would be my suggestion. I can send out a patch that gets
this started later this week.

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[Bpf] Re: [PATCH bpf-next v2] bpf, docs: add LOAD_ACQUIRE and STORE_RELEASE instructions

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 670 bytes --]

On Fri, May 22, 2026 at 10:35:20AM +0200, Alexis Lothoré wrote:

[...]

> I don't know how heavy/long the process is to submit this kind of RFC
> update, but your point makes it sound like it makes more sense to just
> go directly for the proper way, ie adding the conformance group and then
> adding those new ops in there, rather than updating the kernel doc as my
> series is proposing, and then later reverting to a proper conformance
> group.

Hey Alexis,

Apologies for the delay. My email filter was broken so I only just saw
this. Yes, this would be my suggestion. I can send out a patch that gets
this started later this week.

Thanks,
David

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 88 bytes --]

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org