Lines Matching refs:verifier
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
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
192 verifier after a critical section ends. This is necessary to ensure the "will
193 not page fault" property of non-owning references. So if the verifier hasn't
206 allows the verifier to prevent such a state from being valid by simply checking
230 Assume the tree is empty before this program runs. If we track verifier state