Searched refs:kfuncs (Results 1 – 10 of 10) sorted by relevance
| /linux/Documentation/bpf/ |
| H A D | fs_kfuncs.rst | 6 BPF filesystem kfuncs 10 BPF kfuncs can be used to get these data. 16 To avoid recursions, these kfuncs follow the following rules: 18 1. These kfuncs are only permitted from BPF LSM function. 19 2. These kfuncs should not call into other LSM hooks, i.e. security_*(). For
|
| H A D | cpumasks.rst | 6 BPF cpumask kfuncs 18 BPF provides programs with a set of :ref:`kfuncs-header-label` that can be 142 * be passed to kfuncs using RCU protection. 190 3. cpumask kfuncs 193 Above, we described the kfuncs that can be used to allocate, acquire, release, 195 kfuncs for mutating and querying cpumasks. 200 Some cpumask kfuncs are "read-only" in that they don't mutate any of their 204 This section will describe all of the cpumask kfuncs which mutate at least one 205 argument. :ref:`cpumasks-querying-label` below describes the read-only kfuncs. 216 These kfuncs are pretty straightforward, and can be used, for example, as [all …]
|
| H A D | kfuncs.rst | 6 BPF Kernel Functions (kfuncs) 12 BPF Kernel Functions or more commonly known as kfuncs are functions in the Linux 14 kfuncs do not have a stable interface and can change from one kernel release to 56 All kfuncs now require trusted arguments by default. This means that all 67 kfuncs, and may have a non-zero offset. 328 2.5 Annotating kfuncs 331 In addition to kfuncs' arguments, verifier may need more information about the 333 flags on a set of kfuncs as follows:: 349 other kfuncs are similarly protected. An example is given below:: 356 Note that kfuncs must not be declared ``static``. A kfunc can be called from a [all …]
|
| H A D | index.rst | 22 kfuncs
|
| H A D | bpf_design_QA.rst | 206 New BPF functionality is generally added through the use of kfuncs instead of 239 kfuncs. The set of available functions is defined for every program type. 265 A: Yes, through kfuncs and kptrs 269 by exporting kfuncs (which may return pointers to module-internal data 349 for special fields inside them is exposed through kfuncs, and thus has the same 350 lifecycle expectations as the kfuncs themselves. See
|
| H A D | graph_ds_impl.rst | 31 no longer relevant. With the introduction of kfuncs, kptrs, and the any-context 48 or map-specific helpers. The new-style graph data structures instead use kfuncs 50 for kfuncs, the API and semantics for these data structures can be evolved in 266 node. So ``remove``-type kfuncs must be considered a non-owning reference
|
| /linux/tools/testing/selftests/bpf/progs/ |
| H A D | kprobe_multi_session.c | 28 const void *kfuncs[] = { in session_check() local 44 for (i = 0; i < ARRAY_SIZE(kfuncs); i++) { in session_check() 45 if (kfuncs[i] == (void *) addr) { in session_check()
|
| /linux/tools/bpf/bpftool/ |
| H A D | btf.c | 512 struct ptr_array kfuncs = {}; in dump_btf_kfuncs() local 535 err = ptr_array_push(ft, &kfuncs); in dump_btf_kfuncs() 548 qsort_r(kfuncs.elems, kfuncs.cnt, sizeof(*kfuncs.elems), cmp_kfuncs, (void *)btf); in dump_btf_kfuncs() 549 for (i = 0; i < kfuncs.cnt; i++) { in dump_btf_kfuncs() 550 const struct btf_type *t = kfuncs.elems[i]; in dump_btf_kfuncs() 574 ptr_array_free(&kfuncs); in dump_btf_kfuncs()
|
| /linux/tools/bpf/resolve_btfids/ |
| H A D | main.c | 200 struct rb_root kfuncs; member 1002 struct rb_node **p = &ctx->kfuncs.rb_node; in push_kfunc() 1034 rb_insert_color(&k->rb_node, &ctx->kfuncs); in push_kfunc() 1481 for (next = rb_first(&ctx.kfuncs); next; next = rb_next(next)) { in btf2btf() 1508 free_kfuncs(&ctx.kfuncs); in btf2btf()
|
| /linux/Documentation/scheduler/ |
| H A D | sched-ext.rst | 562 ``include/linux/sched/ext.h``, as well as the ``scx_bpf_`` kfuncs defined in
|