bpf: Centralize btf_field-specific initialization logic
authorDave Marchevsky <davemarchevsky@fb.com>
Sat, 15 Apr 2023 20:18:10 +0000 (13:18 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Sun, 16 Apr 2023 00:36:50 +0000 (17:36 -0700)
commit3e81740a90626024a9d9c6f9bfa3d36204dafefb
treefd3df74964919ee3e70c4d4d3e656135787a2f3b
parent404ad75a36fb1a1008e9fe803aa7d0212df9e240
bpf: Centralize btf_field-specific initialization logic

All btf_fields in an object are 0-initialized by memset in
bpf_obj_init. This might not be a valid initial state for some field
types, in which case kfuncs that use the type will properly initialize
their input if it's been 0-initialized. Some BPF graph collection types
and kfuncs do this: bpf_list_{head,node} and bpf_rb_node.

An earlier patch in this series added the bpf_refcount field, for which
the 0 state indicates that the refcounted object should be free'd.
bpf_obj_init treats this field specially, setting refcount to 1 instead
of relying on scattered "refcount is 0? Must have just been initialized,
let's set to 1" logic in kfuncs.

This patch extends this treatment to list and rbtree field types,
allowing most scattered initialization logic in kfuncs to be removed.

Note that bpf_{list_head,rb_root} may be inside a BPF map, in which case
they'll be 0-initialized without passing through the newly-added logic,
so scattered initialization logic must remain for these collection root
types.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
Link: https://lore.kernel.org/r/20230415201811.343116-9-davemarchevsky@fb.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
include/linux/bpf.h
kernel/bpf/helpers.c