Skip to content

Commit 4b2765a

Browse files
committed
Daniel Borkmann says: ==================== pull-request: bpf-next 2024-02-29 We've added 119 non-merge commits during the last 32 day(s) which contain a total of 150 files changed, 3589 insertions(+), 995 deletions(-). The main changes are: 1) Extend the BPF verifier to enable static subprog calls in spin lock critical sections, from Kumar Kartikeya Dwivedi. 2) Fix confusing and incorrect inference of PTR_TO_CTX argument type in BPF global subprogs, from Andrii Nakryiko. 3) Larger batch of riscv BPF JIT improvements and enabling inlining of the bpf_kptr_xchg() for RV64, from Pu Lehui. 4) Allow skeleton users to change the values of the fields in struct_ops maps at runtime, from Kui-Feng Lee. 5) Extend the verifier's capabilities of tracking scalars when they are spilled to stack, especially when the spill or fill is narrowing, from Maxim Mikityanskiy & Eduard Zingerman. 6) Various BPF selftest improvements to fix errors under gcc BPF backend, from Jose E. Marchesi. 7) Avoid module loading failure when the module trying to register a struct_ops has its BTF section stripped, from Geliang Tang. 8) Annotate all kfuncs in .BTF_ids section which eventually allows for automatic kfunc prototype generation from bpftool, from Daniel Xu. 9) Several updates to the instruction-set.rst IETF standardization document, from Dave Thaler. 10) Shrink the size of struct bpf_map resp. bpf_array, from Alexei Starovoitov. 11) Initial small subset of BPF verifier prepwork for sleepable bpf_timer, from Benjamin Tissoires. 12) Fix bpftool to be more portable to musl libc by using POSIX's basename(), from Arnaldo Carvalho de Melo. 13) Add libbpf support to gcc in CORE macro definitions, from Cupertino Miranda. 14) Remove a duplicate type check in perf_event_bpf_event, from Florian Lehner. 15) Fix bpf_spin_{un,}lock BPF helpers to actually annotate them with notrace correctly, from Yonghong Song. 16) Replace the deprecated bpf_lpm_trie_key 0-length array with flexible array to fix build warnings, from Kees Cook. 17) Fix resolve_btfids cross-compilation to non host-native endianness, from Viktor Malik. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (119 commits) selftests/bpf: Test if shadow types work correctly. bpftool: Add an example for struct_ops map and shadow type. bpftool: Generated shadow variables for struct_ops maps. libbpf: Convert st_ops->data to shadow type. libbpf: Set btf_value_type_id of struct bpf_map for struct_ops. bpf: Replace bpf_lpm_trie_key 0-length array with flexible array bpf, arm64: use bpf_prog_pack for memory management arm64: patching: implement text_poke API bpf, arm64: support exceptions arm64: stacktrace: Implement arch_bpf_stack_walk() for the BPF JIT bpf: add is_async_callback_calling_insn() helper bpf: introduce in_sleepable() helper bpf: allow more maps in sleepable bpf programs selftests/bpf: Test case for lacking CFI stub functions. bpf: Check cfi_stubs before registering a struct_ops type. bpf: Clarify batch lookup/lookup_and_delete semantics bpf, docs: specify which BPF_ABS and BPF_IND fields were zero bpf, docs: Fix typos in instruction-set.rst selftests/bpf: update tcp_custom_syncookie to use scalar packet offset bpf: Shrink size of struct bpf_map/bpf_array. ... ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2 parents e960825 + 0270d69 commit 4b2765a

File tree

150 files changed

+3589
-995
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

150 files changed

+3589
-995
lines changed

Documentation/bpf/kfuncs.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -177,10 +177,10 @@ In addition to kfuncs' arguments, verifier may need more information about the
177177
type of kfunc(s) being registered with the BPF subsystem. To do so, we define
178178
flags on a set of kfuncs as follows::
179179

180-
BTF_SET8_START(bpf_task_set)
180+
BTF_KFUNCS_START(bpf_task_set)
181181
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
182182
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
183-
BTF_SET8_END(bpf_task_set)
183+
BTF_KFUNCS_END(bpf_task_set)
184184

185185
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
186186
along with it. Ofcourse, it is also allowed to specify no flags.
@@ -347,10 +347,10 @@ Once the kfunc is prepared for use, the final step to making it visible is
347347
registering it with the BPF subsystem. Registration is done per BPF program
348348
type. An example is shown below::
349349

350-
BTF_SET8_START(bpf_task_set)
350+
BTF_KFUNCS_START(bpf_task_set)
351351
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
352352
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
353-
BTF_SET8_END(bpf_task_set)
353+
BTF_KFUNCS_END(bpf_task_set)
354354

355355
static const struct btf_kfunc_id_set bpf_task_kfunc_set = {
356356
.owner = THIS_MODULE,

Documentation/bpf/map_lpm_trie.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ significant byte.
1717

1818
LPM tries may be created with a maximum prefix length that is a multiple
1919
of 8, in the range from 8 to 2048. The key used for lookup and update
20-
operations is a ``struct bpf_lpm_trie_key``, extended by
20+
operations is a ``struct bpf_lpm_trie_key_u8``, extended by
2121
``max_prefixlen/8`` bytes.
2222

2323
- For IPv4 addresses the data length is 4 bytes

Documentation/bpf/standardization/instruction-set.rst

Lines changed: 89 additions & 66 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
11
.. contents::
22
.. sectnum::
33

4-
=======================================
5-
BPF Instruction Set Specification, v1.0
6-
=======================================
4+
======================================
5+
BPF Instruction Set Architecture (ISA)
6+
======================================
77

8-
This document specifies version 1.0 of the BPF instruction set.
8+
This document specifies the BPF instruction set architecture (ISA).
99

1010
Documentation conventions
1111
=========================
@@ -102,7 +102,7 @@ Conformance groups
102102

103103
An implementation does not need to support all instructions specified in this
104104
document (e.g., deprecated instructions). Instead, a number of conformance
105-
groups are specified. An implementation must support the "basic" conformance
105+
groups are specified. An implementation must support the base32 conformance
106106
group and may support additional conformance groups, where supporting a
107107
conformance group means it must support all instructions in that conformance
108108
group.
@@ -112,12 +112,22 @@ that executes instructions, and tools as such compilers that generate
112112
instructions for the runtime. Thus, capability discovery in terms of
113113
conformance groups might be done manually by users or automatically by tools.
114114

115-
Each conformance group has a short ASCII label (e.g., "basic") that
115+
Each conformance group has a short ASCII label (e.g., "base32") that
116116
corresponds to a set of instructions that are mandatory. That is, each
117117
instruction has one or more conformance groups of which it is a member.
118118

119-
The "basic" conformance group includes all instructions defined in this
120-
specification unless otherwise noted.
119+
This document defines the following conformance groups:
120+
121+
* base32: includes all instructions defined in this
122+
specification unless otherwise noted.
123+
* base64: includes base32, plus instructions explicitly noted
124+
as being in the base64 conformance group.
125+
* atomic32: includes 32-bit atomic operation instructions (see `Atomic operations`_).
126+
* atomic64: includes atomic32, plus 64-bit atomic operation instructions.
127+
* divmul32: includes 32-bit division, multiplication, and modulo instructions.
128+
* divmul64: includes divmul32, plus 64-bit division, multiplication,
129+
and modulo instructions.
130+
* legacy: deprecated packet access instructions.
121131

122132
Instruction encoding
123133
====================
@@ -166,10 +176,10 @@ Note that most instructions do not use all of the fields.
166176
Unused fields shall be cleared to zero.
167177

168178
As discussed below in `64-bit immediate instructions`_, a 64-bit immediate
169-
instruction uses a 64-bit immediate value that is constructed as follows.
179+
instruction uses two 32-bit immediate values that are constructed as follows.
170180
The 64 bits following the basic instruction contain a pseudo instruction
171-
using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
172-
and imm containing the high 32 bits of the immediate value.
181+
using the same format but with 'opcode', 'dst_reg', 'src_reg', and 'offset' all
182+
set to zero, and imm containing the high 32 bits of the immediate value.
173183

174184
This is depicted in the following figure::
175185

@@ -181,13 +191,8 @@ This is depicted in the following figure::
181191
'--------------'
182192
pseudo instruction
183193

184-
Thus the 64-bit immediate value is constructed as follows:
185-
186-
imm64 = (next_imm << 32) | imm
187-
188-
where 'next_imm' refers to the imm value of the pseudo instruction
189-
following the basic instruction. The unused bytes in the pseudo
190-
instruction are reserved and shall be cleared to zero.
194+
Here, the imm value of the pseudo instruction is called 'next_imm'. The unused
195+
bytes in the pseudo instruction are reserved and shall be cleared to zero.
191196

192197
Instruction classes
193198
-------------------
@@ -239,7 +244,8 @@ Arithmetic instructions
239244
-----------------------
240245

241246
``BPF_ALU`` uses 32-bit wide operands while ``BPF_ALU64`` uses 64-bit wide operands for
242-
otherwise identical operations.
247+
otherwise identical operations. ``BPF_ALU64`` instructions belong to the
248+
base64 conformance group unless noted otherwise.
243249
The 'code' field encodes the operation as below, where 'src' and 'dst' refer
244250
to the values of the source and destination registers, respectively.
245251

@@ -284,15 +290,19 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
284290

285291
``BPF_XOR | BPF_K | BPF_ALU`` means::
286292

287-
dst = (u32) dst ^ (u32) imm32
293+
dst = (u32) dst ^ (u32) imm
288294

289295
``BPF_XOR | BPF_K | BPF_ALU64`` means::
290296

291-
dst = dst ^ imm32
297+
dst = dst ^ imm
292298

293299
Note that most instructions have instruction offset of 0. Only three instructions
294300
(``BPF_SDIV``, ``BPF_SMOD``, ``BPF_MOVSX``) have a non-zero offset.
295301

302+
Division, multiplication, and modulo operations for ``BPF_ALU`` are part
303+
of the "divmul32" conformance group, and division, multiplication, and
304+
modulo operations for ``BPF_ALU64`` are part of the "divmul64" conformance
305+
group.
296306
The division and modulo operations support both unsigned and signed flavors.
297307

298308
For unsigned operations (``BPF_DIV`` and ``BPF_MOD``), for ``BPF_ALU``,
@@ -349,7 +359,9 @@ BPF_ALU64 Reserved 0x00 do byte swap unconditionally
349359
========= ========= ===== =================================================
350360

351361
The 'imm' field encodes the width of the swap operations. The following widths
352-
are supported: 16, 32 and 64.
362+
are supported: 16, 32 and 64. Width 64 operations belong to the base64
363+
conformance group and other swap operations belong to the base32
364+
conformance group.
353365

354366
Examples:
355367

@@ -374,31 +386,33 @@ Examples:
374386
Jump instructions
375387
-----------------
376388

377-
``BPF_JMP32`` uses 32-bit wide operands while ``BPF_JMP`` uses 64-bit wide operands for
378-
otherwise identical operations.
389+
``BPF_JMP32`` uses 32-bit wide operands and indicates the base32
390+
conformance group, while ``BPF_JMP`` uses 64-bit wide operands for
391+
otherwise identical operations, and indicates the base64 conformance
392+
group unless otherwise specified.
379393
The 'code' field encodes the operation as below:
380394

381-
======== ===== === =============================== =============================================
382-
code value src description notes
383-
======== ===== === =============================== =============================================
384-
BPF_JA 0x0 0x0 PC += offset BPF_JMP | BPF_K only
385-
BPF_JA 0x0 0x0 PC += imm BPF_JMP32 | BPF_K only
386-
BPF_JEQ 0x1 any PC += offset if dst == src
387-
BPF_JGT 0x2 any PC += offset if dst > src unsigned
388-
BPF_JGE 0x3 any PC += offset if dst >= src unsigned
389-
BPF_JSET 0x4 any PC += offset if dst & src
390-
BPF_JNE 0x5 any PC += offset if dst != src
391-
BPF_JSGT 0x6 any PC += offset if dst > src signed
392-
BPF_JSGE 0x7 any PC += offset if dst >= src signed
393-
BPF_CALL 0x8 0x0 call helper function by address BPF_JMP | BPF_K only, see `Helper functions`_
394-
BPF_CALL 0x8 0x1 call PC += imm BPF_JMP | BPF_K only, see `Program-local functions`_
395-
BPF_CALL 0x8 0x2 call helper function by BTF ID BPF_JMP | BPF_K only, see `Helper functions`_
396-
BPF_EXIT 0x9 0x0 return BPF_JMP | BPF_K only
397-
BPF_JLT 0xa any PC += offset if dst < src unsigned
398-
BPF_JLE 0xb any PC += offset if dst <= src unsigned
399-
BPF_JSLT 0xc any PC += offset if dst < src signed
400-
BPF_JSLE 0xd any PC += offset if dst <= src signed
401-
======== ===== === =============================== =============================================
395+
======== ===== ======= =============================== =============================================
396+
code value src_reg description notes
397+
======== ===== ======= =============================== =============================================
398+
BPF_JA 0x0 0x0 PC += offset BPF_JMP | BPF_K only
399+
BPF_JA 0x0 0x0 PC += imm BPF_JMP32 | BPF_K only
400+
BPF_JEQ 0x1 any PC += offset if dst == src
401+
BPF_JGT 0x2 any PC += offset if dst > src unsigned
402+
BPF_JGE 0x3 any PC += offset if dst >= src unsigned
403+
BPF_JSET 0x4 any PC += offset if dst & src
404+
BPF_JNE 0x5 any PC += offset if dst != src
405+
BPF_JSGT 0x6 any PC += offset if dst > src signed
406+
BPF_JSGE 0x7 any PC += offset if dst >= src signed
407+
BPF_CALL 0x8 0x0 call helper function by address BPF_JMP | BPF_K only, see `Helper functions`_
408+
BPF_CALL 0x8 0x1 call PC += imm BPF_JMP | BPF_K only, see `Program-local functions`_
409+
BPF_CALL 0x8 0x2 call helper function by BTF ID BPF_JMP | BPF_K only, see `Helper functions`_
410+
BPF_EXIT 0x9 0x0 return BPF_JMP | BPF_K only
411+
BPF_JLT 0xa any PC += offset if dst < src unsigned
412+
BPF_JLE 0xb any PC += offset if dst <= src unsigned
413+
BPF_JSLT 0xc any PC += offset if dst < src signed
414+
BPF_JSLE 0xd any PC += offset if dst <= src signed
415+
======== ===== ======= =============================== =============================================
402416

403417
The BPF program needs to store the return value into register R0 before doing a
404418
``BPF_EXIT``.
@@ -424,6 +438,9 @@ specified by the 'imm' field. A > 16-bit conditional jump may be
424438
converted to a < 16-bit conditional jump plus a 32-bit unconditional
425439
jump.
426440

441+
All ``BPF_CALL`` and ``BPF_JA`` instructions belong to the
442+
base32 conformance group.
443+
427444
Helper functions
428445
~~~~~~~~~~~~~~~~
429446

@@ -481,6 +498,8 @@ The size modifier is one of:
481498
BPF_DW 0x18 double word (8 bytes)
482499
============= ===== =====================
483500

501+
Instructions using ``BPF_DW`` belong to the base64 conformance group.
502+
484503
Regular load and store operations
485504
---------------------------------
486505

@@ -493,7 +512,7 @@ instructions that transfer data between a register and memory.
493512

494513
``BPF_MEM | <size> | BPF_ST`` means::
495514

496-
*(size *) (dst + offset) = imm32
515+
*(size *) (dst + offset) = imm
497516

498517
``BPF_MEM | <size> | BPF_LDX`` means::
499518

@@ -525,8 +544,10 @@ by other BPF programs or means outside of this specification.
525544
All atomic operations supported by BPF are encoded as store operations
526545
that use the ``BPF_ATOMIC`` mode modifier as follows:
527546

528-
* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations
529-
* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations
547+
* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations, which are
548+
part of the "atomic32" conformance group.
549+
* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations, which are
550+
part of the "atomic64" conformance group.
530551
* 8-bit and 16-bit wide atomic operations are not supported.
531552

532553
The 'imm' field is used to encode the actual atomic operation.
@@ -547,7 +568,7 @@ BPF_XOR 0xa0 atomic xor
547568

548569
*(u32 *)(dst + offset) += src
549570

550-
``BPF_ATOMIC | BPF_DW | BPF_STX`` with 'imm' = BPF ADD means::
571+
``BPF_ATOMIC | BPF_DW | BPF_STX`` with 'imm' = BPF_ADD means::
551572

552573
*(u64 *)(dst + offset) += src
553574

@@ -580,24 +601,24 @@ and loaded back to ``R0``.
580601
-----------------------------
581602

582603
Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
583-
encoding defined in `Instruction encoding`_, and use the 'src' field of the
604+
encoding defined in `Instruction encoding`_, and use the 'src_reg' field of the
584605
basic instruction to hold an opcode subtype.
585606

586607
The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions
587-
with opcode subtypes in the 'src' field, using new terms such as "map"
608+
with opcode subtypes in the 'src_reg' field, using new terms such as "map"
588609
defined further below:
589610

590-
========================= ====== === ========================================= =========== ==============
591-
opcode construction opcode src pseudocode imm type dst type
592-
========================= ====== === ========================================= =========== ==============
593-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
594-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
595-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
596-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
597-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
598-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
599-
BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
600-
========================= ====== === ========================================= =========== ==============
611+
========================= ====== ======= ========================================= =========== ==============
612+
opcode construction opcode src_reg pseudocode imm type dst type
613+
========================= ====== ======= ========================================= =========== ==============
614+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = (next_imm << 32) | imm integer integer
615+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
616+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
617+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
618+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
619+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
620+
BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
621+
========================= ====== ======= ========================================= =========== ==============
601622

602623
where
603624

@@ -635,7 +656,9 @@ Legacy BPF Packet access instructions
635656
-------------------------------------
636657

637658
BPF previously introduced special instructions for access to packet data that were
638-
carried over from classic BPF. However, these instructions are
639-
deprecated and should no longer be used. All legacy packet access
640-
instructions belong to the "legacy" conformance group instead of the "basic"
641-
conformance group.
659+
carried over from classic BPF. These instructions used an instruction
660+
class of BPF_LD, a size modifier of BPF_W, BPF_H, or BPF_B, and a
661+
mode modifier of BPF_ABS or BPF_IND. The 'dst_reg' and 'offset' fields were
662+
set to zero, and 'src_reg' was set to zero for BPF_ABS. However, these
663+
instructions are deprecated and should no longer be used. All legacy packet
664+
access instructions belong to the "legacy" conformance group.

Documentation/networking/af_xdp.rst

Lines changed: 19 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -329,23 +329,24 @@ XDP_SHARED_UMEM option and provide the initial socket's fd in the
329329
sxdp_shared_umem_fd field as you registered the UMEM on that
330330
socket. These two sockets will now share one and the same UMEM.
331331

332-
There is no need to supply an XDP program like the one in the previous
333-
case where sockets were bound to the same queue id and
334-
device. Instead, use the NIC's packet steering capabilities to steer
335-
the packets to the right queue. In the previous example, there is only
336-
one queue shared among sockets, so the NIC cannot do this steering. It
337-
can only steer between queues.
338-
339-
In libbpf, you need to use the xsk_socket__create_shared() API as it
340-
takes a reference to a FILL ring and a COMPLETION ring that will be
341-
created for you and bound to the shared UMEM. You can use this
342-
function for all the sockets you create, or you can use it for the
343-
second and following ones and use xsk_socket__create() for the first
344-
one. Both methods yield the same result.
332+
In this case, it is possible to use the NIC's packet steering
333+
capabilities to steer the packets to the right queue. This is not
334+
possible in the previous example as there is only one queue shared
335+
among sockets, so the NIC cannot do this steering as it can only steer
336+
between queues.
337+
338+
In libxdp (or libbpf prior to version 1.0), you need to use the
339+
xsk_socket__create_shared() API as it takes a reference to a FILL ring
340+
and a COMPLETION ring that will be created for you and bound to the
341+
shared UMEM. You can use this function for all the sockets you create,
342+
or you can use it for the second and following ones and use
343+
xsk_socket__create() for the first one. Both methods yield the same
344+
result.
345345

346346
Note that a UMEM can be shared between sockets on the same queue id
347347
and device, as well as between queues on the same device and between
348-
devices at the same time.
348+
devices at the same time. It is also possible to redirect to any
349+
socket as long as it is bound to the same umem with XDP_SHARED_UMEM.
349350

350351
XDP_USE_NEED_WAKEUP bind flag
351352
-----------------------------
@@ -822,6 +823,10 @@ A: The short answer is no, that is not supported at the moment. The
822823
switch, or other distribution mechanism, in your NIC to direct
823824
traffic to the correct queue id and socket.
824825

826+
Note that if you are using the XDP_SHARED_UMEM option, it is
827+
possible to switch traffic between any socket bound to the same
828+
umem.
829+
825830
Q: My packets are sometimes corrupted. What is wrong?
826831

827832
A: Care has to be taken not to feed the same buffer in the UMEM into

arch/arm64/include/asm/patching.h

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,8 @@ int aarch64_insn_read(void *addr, u32 *insnp);
88
int aarch64_insn_write(void *addr, u32 insn);
99

1010
int aarch64_insn_write_literal_u64(void *addr, u64 val);
11+
void *aarch64_insn_set(void *dst, u32 insn, size_t len);
12+
void *aarch64_insn_copy(void *dst, void *src, size_t len);
1113

1214
int aarch64_insn_patch_text_nosync(void *addr, u32 insn);
1315
int aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt);

0 commit comments

Comments
 (0)