| /linux/Documentation/bpf/ |
| A D | graph_ds_impl.rst | 6 structures (linked_list, rbtree), with particular focus on the verifier's
9 Although no specific verifier code is referred to in this document, the document
10 assumes that the reader has general knowledge of BPF verifier internals, BPF
37 "node"s, the verifier code and this document refer to common functionality
75 variables are placed in a single-value arraymap. The verifier considers this
109 What should the verifier do with ``n`` after ownership is passed off? If the
133 Both the read from and write to ``n->data`` would be rejected. The verifier
153 The verifier considers such a reference a *non-owning reference*. The ref
168 * If not released before program ends, verifier considers program invalid
184 From verifier's perspective non-owning references can only exist
[all …]
|
| A D | verifier.rst | 3 eBPF verifier
18 If verifier sees an insn that does R2=R1, then R2 has now type
70 the verifier will reject the program.
104 Seccomp solves this by two stage verifier: classic BPF verifier is followed
105 by seccomp verifier. In case of eBPF one configurable verifier is shared for
108 See details of eBPF verifier in kernel/bpf/verifier.c
390 verifier state creation;
394 verifier state itself;
397 is read by a some child state of this verifier state;
535 verifier state becomes a valid entry in a set of cached verifier states.
[all …]
|
| A D | kfuncs.rst | 57 by the verifier to make the usage of kernel functions safer and more useful.
72 Here, the verifier will treat first argument as a PTR_TO_MEM, and second
81 the verifier must check the scalar argument to be a known constant, which does
95 values don't match during verifier state pruning checks.
115 annotation, the verifier will reject the program if the dynptr passed in is
208 referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the
254 that to the verifier:
369 The verifier will always enforce that the BTF type of a pointer passed to a
371 definition. The verifier, does, however, allow types that are equivalent
500 programs calling the kfunc will be rejected by the verifier.
[all …]
|
| A D | bpf_design_QA.rst | 90 Q: What are the verifier limits?
94 program can have. The verifier has various internal limits.
100 calls, a limit to the number of the verifier states per instruction,
104 to be rejected. The verifier used to recognize only pointer + constant
108 The verifier is steadily getting 'smarter'. The limits are
110 be accepted by the verifier is to try to load it.
178 compiling a program. Furthermore, the verifier can now mark the
186 enable zext insertion in the verifier).
189 support for zext. In that case, if verifier zext insertion is enabled,
225 space, but the verifier computes the actual amount of stack used
[all …]
|
| A D | index.rst | 15 verifier
|
| A D | clang-notes.rst | 27 instruction, which is not supported by the Linux kernel verifier.
|
| A D | ringbuf.rst | 49 infrastructure that has to be built for observability and verifier support. It
98 submit records of the length that's not known to verifier beforehand. It also
107 be reserved, such that verifier can verify that BPF program can't access memory
118 Each reserved record is tracked by verifier through existing
175 header. This significantly simplifies verifier, as well as improving API
|
| A D | prog_lsm.rst | 90 the BPF verifier to update the offsets for the access at runtime using the
91 Documentation/bpf/btf.rst information. Since the BPF verifier is aware of the
|
| A D | bpf_devel_QA.rst | 250 Q: I made a BPF verifier change, do I need to add test cases for
253 A: If the patch has changes to the behavior of the verifier, then yes,
262 affect prior use-cases. Thus, treat those test cases as: verifier
454 To run the verifier tests::
458 The verifier tests print out all the current checks being
508 existing ones are adapted to verifier changes e.g. due to verifier
576 generation back end or about LLVM generated code that the verifier
685 into these structures is verified by the BPF verifier and may result
|
| A D | linux-notes.rst | 20 by the verifier. Any programs with this instruction will fail to load
|
| /linux/fs/nfs/ |
| A D | nfstrace.h | 327 const __be32 *verifier,
340 __array(char, verifier, NFS4_VERIFIER_SIZE)
355 memcpy(__entry->verifier, verifier,
358 memset(__entry->verifier, 0,
380 const __be32 *verifier, \
1373 memcpy(__entry->verifier,
1374 &verf->verifier,
1391 show_nfs4_verifier(__entry->verifier)
1512 memcpy(__entry->verifier,
1513 &verf->verifier,
[all …]
|
| A D | nfs3xdr.c | 272 static __be32 *xdr_encode_cookieverf3(__be32 *p, const __be32 *verifier) in xdr_encode_cookieverf3() argument
274 memcpy(p, verifier, NFS3_COOKIEVERFSIZE); in xdr_encode_cookieverf3()
278 static int decode_cookieverf3(struct xdr_stream *xdr, __be32 *verifier) in decode_cookieverf3() argument
285 memcpy(verifier, p, NFS3_COOKIEVERFSIZE); in decode_cookieverf3()
294 static void encode_createverf3(struct xdr_stream *xdr, const __be32 *verifier) in encode_createverf3() argument
299 memcpy(p, verifier, NFS3_CREATEVERFSIZE); in encode_createverf3()
302 static int decode_writeverf3(struct xdr_stream *xdr, struct nfs_write_verifier *verifier) in decode_writeverf3() argument
309 memcpy(verifier->data, p, NFS3_WRITEVERFSIZE); in decode_writeverf3()
1026 encode_createverf3(xdr, args->verifier); in encode_createhow3()
1700 if (decode_writeverf3(xdr, &result->verf->verifier)) in decode_write3resok()
[all …]
|
| A D | nfs42proc.c | 243 memcpy(&res->write_res.verifier, ©->verf, sizeof(copy->verf)); in handle_async_copy()
269 if (nfs_write_verifier_cmp(&res->write_res.verifier.verifier, in process_copy_commit()
270 &cres.verf->verifier)) { in process_copy_commit()
383 nfs_write_verifier_cmp(&res->write_res.verifier.verifier, in _nfs42_proc_copy()
384 &res->commit_res.verf->verifier)) { in _nfs42_proc_copy()
397 res->write_res.verifier.committed != NFS_FILE_SYNC) { in _nfs42_proc_copy()
|
| A D | localio.c | 411 nfs_copy_boot_verifier(struct nfs_write_verifier *verifier, struct inode *inode) in nfs_copy_boot_verifier() argument
414 u32 *verf = (u32 *)verifier->data; in nfs_copy_boot_verifier()
440 nfs_copy_boot_verifier(&verf->verifier, inode); in nfs_set_local_verifier()
|
| A D | callback_proc.c | 705 memcpy(&cp_state->verf.verifier.data[0], in nfs4_copy_cb_args()
706 &args->wr_writeverf.verifier.data[0], in nfs4_copy_cb_args()
|
| /linux/tools/testing/selftests/bpf/ |
| A D | veristat.cfg | 2 # BPF verifier's performance on
|
| A D | README.rst | 137 // the instructions below will not be seen in the verifier log
142 The verifier will reject such code with above error.
145 verifier to understand such speculative pointer arithmetic.
206 The verifier output looks like
234 This cause later verifier failure. The bug has been `fixed`__ in
|
| A D | Makefile | 785 verifier/tests.h: verifier/*.c
786 $(shell ( cd verifier/; \
791 ) > verifier/tests.h)
792 $(OUTPUT)/test_verifier: test_verifier.c verifier/tests.h $(BPFOBJ) | $(OUTPUT)
870 prog_tests/tests.h map_tests/tests.h verifier/tests.h \
|
| /linux/tools/bpf/bpftool/Documentation/ |
| A D | common_options.rst | 23 from libbpf as well as from the verifier, when attempting to load programs.
|
| /linux/include/linux/ |
| A D | nfs_xdr.h | 484 nfs4_verifier verifier; /* EXCLUSIVE */ member
660 struct nfs_write_verifier verifier; member
946 __be32 verifier[2]; member
1163 nfs4_verifier verifier; member
1173 nfs4_verifier verifier; member
1357 nfs4_verifier verifier; member
1504 struct nfs_writeverf verifier; member
|
| /linux/kernel/bpf/ |
| A D | Makefile | 9 obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o log.o token.o
|
| /linux/drivers/net/ethernet/netronome/nfp/ |
| A D | Makefile | 71 bpf/verifier.o \
|
| /linux/Documentation/filesystems/nfs/ |
| A D | client-identifier.rst | 56 - boot verifier: A 64-bit incarnation verifier that enables a
98 client presents a different boot verifier, so it appears to the
|
| /linux/Documentation/filesystems/xfs/ |
| A D | xfs-self-describing-metadata.rst | 221 A typical buffer read verifier is structured as follows::
244 The verifier function will take a couple of different forms, depending on
272 If there are different magic numbers for the different formats, the verifier
298 the opposite order to the read verifiers. A typical write verifier::
|
| /linux/samples/bpf/ |
| A D | README.rst | 4 This directory contains a test stubs, verifier test-suite and examples
|