Lines Matching refs:owning

81 Non-owning references
153 The verifier considers such a reference a *non-owning reference*. The ref
154 returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
161 *owning reference*
172 *non-owning reference*
180     non-owning ref existence (see explanation below)
184 From verifier's perspective non-owning references can only exist
187 via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,
191 To prevent this logic violation all non-owning references are invalidated by the
193 not page fault" property of non-owning references. So if the verifier hasn't
194 invalidated a non-owning ref, accessing it will not page fault.
197 if there's a valid non-owning ref, we must be in a critical section, and can
201 Any reference to a node that is in an rbtree _must_ be non-owning, since
203 that isn't in rbtree _must_ be owning. This results in a nice property:
233   1) n is an owning reference
235   2) n is a non-owning reference, it's been added to the tree
237   3) n and m are non-owning references, they both point to the same node
239   4) o is an owning reference, n and m non-owning, all point to same node
241   5) o and p are owning, n and m non-owning, all point to the same node
246 States 4 and 5 violate our "nice property", as there are non-owning refs to
255 We prevent both by generalizing the "invalidate non-owning references" behavior
263   * returns an owning reference to the removed node
265 May result in a state where some other non-owning reference points to the same
266 node. So ``remove``-type kfuncs must be considered a non-owning reference