| /linux/Documentation/bpf/ |
| H 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
98 From the verifier's perspective, the pointer ``n`` returned from ``bpf_obj_new``
109 What should the verifier do with ``n`` after ownership is passed off? If the
110 object was ``free``'d with ``bpf_obj_drop`` the answer is obvious: the verifier
116 obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
133 Both the read from and write to ``n->data`` would be rejected. The verifier
[all …]
|
| H 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 …]
|
| H 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
|
| H A D | clang-notes.rst | 27 instruction, which is not supported by the Linux kernel verifier.
|
| H 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
|
| H 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
462 To run the verifier tests::
466 The verifier tests print out all the current checks being
516 existing ones are adapted to verifier changes e.g. due to verifier
584 generation back end or about LLVM generated code that the verifier
694 into these structures is verified by the BPF verifier and may result
|
| H A D | linux-notes.rst | 20 by the verifier. Any programs with this instruction will fail to load
|
| H A D | map_cpumap.rst | 51 program will result in the program failing to load and a verifier warning.
|
| H A D | prog_flow_dissector.rst | 14 in BPF to gain all the benefits of BPF verifier (namely, limits on the
|
| H A D | map_xskmap.rst | 90 result in the program failing to load and a verifier warning.
|
| /linux/fs/nfs/ |
| H A D | nfstrace.h | 350 const __be32 *verifier,
356 TP_ARGS(file, verifier, cookie, page_index, dtsize),
363 __array(char, verifier, NFS4_VERIFIER_SIZE)
378 memcpy(__entry->verifier, verifier,
381 memset(__entry->verifier, 0,
393 __entry->version, show_nfs4_verifier(__entry->verifier),
403 const __be32 *verifier, \
408 TP_ARGS(file, verifier, cookie, page_index, dtsize))
1451 __array(char, verifier, NFS4_VERIFIER_SIZE)
1466 memcpy(__entry->verifier,
[all …]
|
| H 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 …]
|
| H A D | nfs42proc.c | 302 memcpy(&res->write_res.verifier, ©->verf, sizeof(copy->verf)); in handle_async_copy()
361 if (nfs_write_verifier_cmp(&res->write_res.verifier.verifier, in process_copy_commit()
362 &cres.verf->verifier)) { in process_copy_commit()
483 nfs_write_verifier_cmp(&res->write_res.verifier.verifier, in _nfs42_proc_copy()
484 &res->commit_res.verf->verifier)) { in _nfs42_proc_copy()
497 res->write_res.verifier.committed != NFS_FILE_SYNC) { in _nfs42_proc_copy()
|
| H A D | localio.c | 718 nfs_copy_boot_verifier(struct nfs_write_verifier *verifier, struct inode *inode) in nfs_copy_boot_verifier() argument
721 u32 *verf = (u32 *)verifier->data; in nfs_copy_boot_verifier()
746 nfs_copy_boot_verifier(&verf->verifier, inode); in nfs_set_local_verifier()
|
| H A D | callback_proc.c | 707 memcpy(&cp_state->verf.verifier.data[0], in nfs4_copy_cb_args()
708 &args->wr_writeverf.verifier.data[0], in nfs4_copy_cb_args()
|
| H A D | nfs42xdr.c | 902 res->verifier.committed = be32_to_cpup(p); in decode_write_response()
903 return decode_verifier(xdr, &res->verifier.verifier); in decode_write_response()
|
| /linux/tools/testing/selftests/bpf/ |
| H A D | veristat.cfg | 2 # BPF verifier's performance on
|
| H 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
|
| H A D | Makefile | 801 verifier/tests.h: verifier/*.c
802 $(shell ( cd verifier/; \
807 ) > verifier/tests.h)
808 $(OUTPUT)/test_verifier: test_verifier.c verifier/tests.h $(BPFOBJ) | $(OUTPUT)
898 prog_tests/tests.h map_tests/tests.h verifier/tests.h \
|
| /linux/tools/bpf/bpftool/Documentation/ |
| H A D | common_options.rst | 23 from libbpf as well as from the verifier, when attempting to load programs.
|
| /linux/drivers/net/ethernet/netronome/nfp/ |
| H A D | Makefile | 71 bpf/verifier.o \
|
| /linux/kernel/bpf/ |
| H A D | Makefile | 9 obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o log.o token.o liveness.o
|
| /linux/Documentation/filesystems/nfs/ |
| H 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/ |
| H 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/ |
| H A D | README.rst | 4 This directory contains a test stubs, verifier test-suite and examples
|