Searched refs:bpf_obj_drop (Results 1 – 7 of 7) sorted by relevance
29 bpf_obj_drop(f); in list_push_pop()38 bpf_obj_drop(f); in list_push_pop()56 bpf_obj_drop(f); in list_push_pop()71 bpf_obj_drop(f); in list_push_pop()74 bpf_obj_drop(f); in list_push_pop()157 bpf_obj_drop(pf); in list_push_pop_multiple()191 bpf_obj_drop(f); in list_in_list()215 bpf_obj_drop(f); in list_in_list()233 bpf_obj_drop(b); in list_in_list()239 bpf_obj_drop(f); in list_in_list()[all …]
47 bpf_obj_drop(n); in __add_three()99 bpf_obj_drop(n); in rbtree_add_and_remove()104 bpf_obj_drop(n); in rbtree_add_and_remove()106 bpf_obj_drop(m); in rbtree_add_and_remove()154 bpf_obj_drop(o); in rbtree_first_and_remove()170 bpf_obj_drop(n); in rbtree_first_and_remove()172 bpf_obj_drop(m); in rbtree_first_and_remove()
37 bpf_obj_drop(f1); \42 bpf_obj_drop(f2); \43 bpf_obj_drop(f1); \244 bpf_obj_drop(f+1); in obj_drop_non_zero_off()269 bpf_obj_drop(f); in use_after_drop()545 bpf_obj_drop(f); in incorrect_head_off1()
84 bpf_obj_drop(n); in rbtree_api_remove_unadded_node()101 bpf_obj_drop(n); in rbtree_api_remove_unadded_node()103 bpf_obj_drop(m); in rbtree_api_remove_unadded_node()
105 bpf_obj_drop(f1); \
103 ``bpf_obj_drop``, which ``free``'s the object, or by adding it to ``tree`` with110 object was ``free``'d with ``bpf_obj_drop`` the answer is obvious: the verifier111 should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as116 obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,166 kfunc, or via ``bpf_obj_drop``, which ``free``'s the pointee177 ``bpf_obj_drop``187 via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,196 Currently ``bpf_obj_drop`` is not allowed in the critical section, so227 bpf_obj_drop(o);228 bpf_obj_drop(p); /* 6 */
38 #define bpf_obj_drop(kptr) bpf_obj_drop_impl(kptr, NULL) macro
Completed in 17 milliseconds