bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure
@ 2022-12-17  8:24 Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs Dave Marchevsky
                   ` (12 more replies)
  0 siblings, 13 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

This series adds a rbtree datastructure following the "next-gen
datastructure" precedent set by recently-added linked-list [0]. This is
a reimplementation of previous rbtree RFC [1] to use kfunc + kptr
instead of adding a new map type. This series adds a smaller set of API
functions than that RFC - just the minimum needed to support current
cgfifo example scheduler in ongoing sched_ext effort [2], namely:

  bpf_rbtree_add
  bpf_rbtree_remove
  bpf_rbtree_first

The meat of this series is bugfixes and verifier infra work to support
these API functions. Adding more rbtree kfuncs in future patches should
be straightforward as a result.

First, the series refactors and extends linked_list's release_on_unlock
logic. The concept of "reference to node that was added to data
structure" is formalized as "non-owning reference". From linked_list's
perspective this non-owning reference after
linked_list_push_{front,back} has same semantics as release_on_unlock,
with the addition of writes to such references being valid in the
critical section. Such references are no longer marked PTR_UNTRUSTED.
Patches 2 and 13 go into more detail.

The series then adds rbtree API kfuncs and necessary verifier support
for them - namely support for callback args to kfuncs and some
non-owning reference interactions that linked_list didn't need.

BPF rbtree uses struct rb_root_cached + existing rbtree lib under the
hood. From the BPF program writer's perspective, a BPF rbtree is very
similar to existing linked list. Consider the following example:

  struct node_data {
    long key;
    long data;
    struct bpf_rb_node node;
  }

  static bool less(struct bpf_rb_node *a, const struct bpf_rb_node *b)
  {
    struct node_data *node_a;
    struct node_data *node_b;

    node_a = container_of(a, struct node_data, node);
    node_b = container_of(b, struct node_data, node);

    return node_a->key < node_b->key;
  }

  private(A) struct bpf_spin_lock glock;
  private(A) struct bpf_rb_root groot __contains(node_data, node);

  /* ... in BPF program */
  struct node_data *n, *m;
  struct bpf_rb_node *res;

  n = bpf_obj_new(typeof(*n));
  if (!n)
    /* skip */
  n->key = 5;
  n->data = 10;

  bpf_spin_lock(&glock);
  bpf_rbtree_add(&groot, &n->node, less);
  bpf_spin_unlock(&glock);

  bpf_spin_lock(&glock);
  res = bpf_rbtree_first(&groot);
  if (!res)
    /* skip */
  res = bpf_rbtree_remove(&groot, res);
  if (!res)
    /* skip */
  bpf_spin_unlock(&glock);

  m = container_of(res, struct node_data, node);
  bpf_obj_drop(m);

Some obvious similarities:

  * Special bpf_rb_root and bpf_rb_node types have same semantics
    as bpf_list_head and bpf_list_node, respectively
  * __contains is used to associated node type with root
  * The spin_lock associated with a rbtree must be held when using
    rbtree API kfuncs
  * Nodes are allocated via bpf_obj_new and dropped via bpf_obj_drop
  * Rbtree takes ownership of node lifetime when a node is added.
    Removing a node gives ownership back to the program, requiring a
    bpf_obj_drop before program exit

Some new additions as well:

  * Support for callbacks in kfunc args is added to enable 'less'
    callback use above
  * bpf_rbtree_first is the first graph API function to return a
    non-owning reference instead of convering an arg from own->non-own
  * Because all references to nodes already added to the rbtree are
    non-owning, bpf_rbtree_remove must accept such a reference in order
    to remove it from the tree

Summary of patches:
  Patch 1 lays groundwork for release_on_unlock -> non-owning ref
  changes

  Patches 2 and 3 do release_on_unlock -> non-owning ref migration and
  update linked_list tests

  Patch 4 is a nonfunctional rename

  Patches 5 - 9 implement the meat of rbtree support in this series,
  gradually building up to implemented kfuncs that verify as expected.

  Patch 10 adds the bpf_rbtree_{add,first,remove} to bpf_experimental.h.

  Patch 12 adds tests, Patch 13 adds documentation.

  [0]: lore.kernel.org/bpf/20221118015614.2013203-1-memxor@gmail.com
  [1]: lore.kernel.org/bpf/20220830172759.4069786-1-davemarchevsky@fb.com
  [2]: lore.kernel.org/bpf/20221130082313.3241517-1-tj@kernel.org

Changelog:

v1 -> v2: lore.kernel.org/bpf/20221206231000.3180914-1-davemarchevsky@fb.com/

Series-wide changes:
  * Rename datastructure_{head,node,api} -> graph_{root,node,api} (Alexei)
  * "graph datastructure" in patch summaries to refer to linked_list + rbtree
    instead of "next-gen datastructure" (Alexei)
  * Move from hacky marking of non-owning references as PTR_UNTRUSTED to
    cleaner implementation (Alexei)
  * Add invalidation of non-owning refs to rbtree_remove (Kumar, Alexei)

Patch #'s below refer to the patch's number in v1 unless otherwise stated.

Note that in v1 most of the meaty verifier changes were in the latter half
of the series. Here, about half of that complexity has been moved to
"bpf: Migrate release_on_unlock logic to non-owning ref semantics" - was Patch
3 in v1.

* Patch 1 - "bpf: Loosen alloc obj test in verifier's reg_btf_record"
  * Was applied, dropped from further iterations

* Patch 2 - "bpf: map_check_btf should fail if btf_parse_fields fails"
  * Dropped in favor of verifier check-on-use: when some normal verifier
    checking expects the map to have btf_fields correctly parsed, it won't
    find any and verification will fail

* New patch added before Patch 3 - "bpf: Support multiple arg regs w/ ref_obj_id for kfuncs"
  * Addition of KF_RELEASE_NON_OWN flag, which requires KF_RELEASE, and tagging
    of bpf_list_push_{front,back} KF_RELEASE | KF_RELEASE_NON_OWN, means that
    list-in-list push_{front,back} will trigger "only one ref_obj_id arg reg"
    logic. This is because "head" arg to those functions can be a list-in-list,
    which itself can be an owning reference with ref_obj_id. So need to
    support multiple ref_obj_id for release kfuncs.

* Patch 3 - "bpf: Minor refactor of ref_set_release_on_unlock"
  * Now a major refactor w/ a rename to reflect this
    * "bpf: Migrate release_on_unlock logic to non-owning ref semantics"
  * Replaces release_on_unlock with active_lock logic as discussed in v1

* New patch added after Patch 3 - "selftests/bpf: Update linked_list tests for non_owning_ref logic"
  * Removes "write after push" linked_list failure tests - no longer failure
    scenarios.

* Patch 4 - "bpf: rename list_head -> datastructure_head in field info types"
  * rename to graph_root instead. Similar renamings across the series - see
    series-wide changes.

* Patch 5 - "bpf: Add basic bpf_rb_{root,node} support"
  * OWNER_FIELD_MASK -> GRAPH_ROOT_MASK, OWNEE_FIELD_MASK -> GRAPH_NODE_MASK,
    and change of "owner"/"ownee" in big btf_check_and_fixup_fields comment to
    "root"/"node" (Alexei)

* Patch 6 - "bpf: Add bpf_rbtree_{add,remove,first} kfuncs"
  * bpf_rbtree_remove can no longer return NULL. v2 continues v1's "use type
    system to prevent remove of node that isn't in a datastructure" approach,
    so rbtree_remove should never have been able to return NULL

* Patch 7 - "bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args"
  * is_bpf_datastructure_api_kfunc -> is_bpf_graph_api_kfunc (Alexei)

* Patch 8 - "bpf: Add callback validation to kfunc verifier logic"
  * Explicitly disallow rbtree_remove in rbtree callback
  * Explicitly disallow bpf_spin_{lock,unlock} call in rbtree callback,
    preventing possibility of "unbalanced" unlock (Alexei)

* Patch 10 - "bpf, x86: BPF_PROBE_MEM handling for insn->off < 0"
  * Now that non-owning refs aren't marked PTR_UNTRUSTED it's not necessary to
    include this patch as part of the series
  * After conversation w/ Alexei, did another pass and submitted as an
    independent series (lore.kernel.org/bpf/20221213182726.325137-1-davemarchevsky@fb.com/)

* Patch 13 - "selftests/bpf: Add rbtree selftests"
  * Since bpf_rbtree_remove can no longer return null, remove null checks
  * Remove test confirming that rbtree_first isn't allowed in callback. We want
    this to be possible
  * Add failure test confirming that rbtree_remove's new non-owning reference
    invalidation behavior behaves as expected
  * Add SEC("license") to rbtree_btf_fail__* progs. They were previously
    failing due to lack of this section. Now they're failing for correct
    reasons.
  * rbtree_btf_fail__add_wrong_type.c - add locking around rbtree_add, rename
    the bpf prog to something reasonable

* New patch added after patch 13 - "bpf, documentation: Add graph documentation for non-owning refs"
  * Summarizes details of owning and non-owning refs which we hashed out in
    v1


Dave Marchevsky (13):
  bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  bpf: Migrate release_on_unlock logic to non-owning ref semantics
  selftests/bpf: Update linked_list tests for non-owning ref semantics
  bpf: rename list_head -> graph_root in field info types
  bpf: Add basic bpf_rb_{root,node} support
  bpf: Add bpf_rbtree_{add,remove,first} kfuncs
  bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args
  bpf: Add callback validation to kfunc verifier logic
  bpf: Special verifier handling for bpf_rbtree_{remove, first}
  bpf: Add bpf_rbtree_{add,remove,first} decls to bpf_experimental.h
  libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj
    type
  selftests/bpf: Add rbtree selftests
  bpf, documentation: Add graph documentation for non-owning refs

 Documentation/bpf/graph_ds_impl.rst           | 208 +++++
 Documentation/bpf/other.rst                   |   3 +-
 include/linux/bpf.h                           |  23 +-
 include/linux/bpf_verifier.h                  |  39 +-
 include/linux/btf.h                           |  18 +-
 include/uapi/linux/bpf.h                      |  11 +
 kernel/bpf/btf.c                              | 181 ++--
 kernel/bpf/helpers.c                          |  76 +-
 kernel/bpf/syscall.c                          |  28 +-
 kernel/bpf/verifier.c                         | 800 ++++++++++++++----
 tools/include/uapi/linux/bpf.h                |  11 +
 tools/lib/bpf/libbpf.c                        |  50 +-
 .../testing/selftests/bpf/bpf_experimental.h  |  24 +
 .../selftests/bpf/prog_tests/linked_list.c    |  22 +-
 .../testing/selftests/bpf/prog_tests/rbtree.c | 186 ++++
 .../testing/selftests/bpf/progs/linked_list.c |   2 +-
 .../selftests/bpf/progs/linked_list_fail.c    | 100 ++-
 tools/testing/selftests/bpf/progs/rbtree.c    | 176 ++++
 .../progs/rbtree_btf_fail__add_wrong_type.c   |  52 ++
 .../progs/rbtree_btf_fail__wrong_node_type.c  |  49 ++
 .../testing/selftests/bpf/progs/rbtree_fail.c | 296 +++++++
 21 files changed, 2018 insertions(+), 337 deletions(-)
 create mode 100644 Documentation/bpf/graph_ds_impl.rst
 create mode 100644 tools/testing/selftests/bpf/prog_tests/rbtree.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree_btf_fail__add_wrong_type.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree_btf_fail__wrong_node_type.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree_fail.c

-- 
2.30.2

^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
@ 2022-12-17  8:24 ` Dave Marchevsky
  2022-12-29  3:24   ` Alexei Starovoitov
  2022-12-29  6:40   ` David Vernet
  2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
                   ` (11 subsequent siblings)
  12 siblings, 2 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

Currently, kfuncs marked KF_RELEASE indicate that they release some
previously-acquired arg. The verifier assumes that such a function will
only have one arg reg w/ ref_obj_id set, and that that arg is the one to
be released. Multiple kfunc arg regs have ref_obj_id set is considered
an invalid state.

For helpers, RELEASE is used to tag a particular arg in the function
proto, not the function itself. The arg with OBJ_RELEASE type tag is the
arg that the helper will release. There can only be one such tagged arg.
When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
also considered an invalid state.

Later patches in this series will result in some linked_list helpers
marked KF_RELEASE having a valid reason to take two ref_obj_id args.
Specifically, bpf_list_push_{front,back} can push a node to a list head
which is itself part of a list node. In such a scenario both arguments
to these functions would have ref_obj_id > 0, thus would fail
verification under current logic.

This patch changes kfunc ref_obj_id searching logic to find the last arg
reg w/ ref_obj_id and consider that the reg-to-release. This should be
backwards-compatible with all current kfuncs as they only expect one
such arg reg.

Currently the ref_obj_id and OBJ_RELEASE searching is done in the code
that examines each individual arg (check_func_arg for helpers and
check_kfunc_args inner loop for kfuncs). This patch pulls out this
searching to occur before individual arg type handling, resulting in a
cleaner separation of logic.

Two new helpers are added:
  * args_find_ref_obj_id_regno
    * For helpers and kfuncs. Searches through arg regs to find
      ref_obj_id reg and returns its regno. Helpers set allow_multi =
      false, retaining "only one ref_obj_id arg" behavior, while kfuncs
      set allow_multi = true and get the last ref_obj_id arg reg back.

  * helper_proto_find_release_arg_regno
    * For helpers only. Searches through fn proto args to find the
      OBJ_RELEASE arg and returns the corresponding regno.

Aside from the intentional semantic change for kfuncs, the rest of the
refactoring strives to keep failure logic and error messages unchanged.
However, because the release arg searching is now done before any
arg-specific type checking, verifier states that are invalid due to both
invalid release arg state _and_ some type- or helper-specific checking
might see release arg-related error message first.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 kernel/bpf/verifier.c | 206 ++++++++++++++++++++++++++++--------------
 1 file changed, 138 insertions(+), 68 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a5255a0dcbb6..824e2242eae5 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -6412,49 +6412,6 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
 		return err;
 
 skip_type_check:
-	if (arg_type_is_release(arg_type)) {
-		if (arg_type_is_dynptr(arg_type)) {
-			struct bpf_func_state *state = func(env, reg);
-			int spi;
-
-			/* Only dynptr created on stack can be released, thus
-			 * the get_spi and stack state checks for spilled_ptr
-			 * should only be done before process_dynptr_func for
-			 * PTR_TO_STACK.
-			 */
-			if (reg->type == PTR_TO_STACK) {
-				spi = get_spi(reg->off);
-				if (!is_spi_bounds_valid(state, spi, BPF_DYNPTR_NR_SLOTS) ||
-				    !state->stack[spi].spilled_ptr.ref_obj_id) {
-					verbose(env, "arg %d is an unacquired reference\n", regno);
-					return -EINVAL;
-				}
-			} else {
-				verbose(env, "cannot release unowned const bpf_dynptr\n");
-				return -EINVAL;
-			}
-		} else if (!reg->ref_obj_id && !register_is_null(reg)) {
-			verbose(env, "R%d must be referenced when passed to release function\n",
-				regno);
-			return -EINVAL;
-		}
-		if (meta->release_regno) {
-			verbose(env, "verifier internal error: more than one release argument\n");
-			return -EFAULT;
-		}
-		meta->release_regno = regno;
-	}
-
-	if (reg->ref_obj_id) {
-		if (meta->ref_obj_id) {
-			verbose(env, "verifier internal error: more than one arg with ref_obj_id R%d %u %u\n",
-				regno, reg->ref_obj_id,
-				meta->ref_obj_id);
-			return -EFAULT;
-		}
-		meta->ref_obj_id = reg->ref_obj_id;
-	}
-
 	switch (base_type(arg_type)) {
 	case ARG_CONST_MAP_PTR:
 		/* bpf_map_xxx(map_ptr) call: remember that map_ptr */
@@ -6565,6 +6522,27 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
 		err = check_mem_size_reg(env, reg, regno, true, meta);
 		break;
 	case ARG_PTR_TO_DYNPTR:
+		if (meta->release_regno == regno) {
+			struct bpf_func_state *state = func(env, reg);
+			int spi;
+
+			/* Only dynptr created on stack can be released, thus
+			 * the get_spi and stack state checks for spilled_ptr
+			 * should only be done before process_dynptr_func for
+			 * PTR_TO_STACK.
+			 */
+			if (reg->type == PTR_TO_STACK) {
+				spi = get_spi(reg->off);
+				if (!is_spi_bounds_valid(state, spi, BPF_DYNPTR_NR_SLOTS) ||
+				    !state->stack[spi].spilled_ptr.ref_obj_id) {
+					verbose(env, "arg %d is an unacquired reference\n", regno);
+					return -EINVAL;
+				}
+			} else {
+				verbose(env, "cannot release unowned const bpf_dynptr\n");
+				return -EINVAL;
+			}
+		}
 		err = process_dynptr_func(env, regno, arg_type, meta);
 		if (err)
 			return err;
@@ -7699,10 +7677,78 @@ static void update_loop_inline_state(struct bpf_verifier_env *env, u32 subprogno
 				 state->callback_subprogno == subprogno);
 }
 
+/* Call arg meta's ref_obj_id is used to either:
+ *   - For release funcs, keep track of ref that needs to be released
+ *   - For other funcs, keep track of ref that needs to be propagated to retval
+ *
+ * Find and return:
+ *   - Regno that should become meta->ref_obj_id on success
+ *     (regno > 0 since BPF_REG_1 is first arg)
+ *   - 0 if no arg had ref_obj_id set
+ *   - Negative err if some invalid arg reg state
+ *
+ * allow_multi controls whether multiple args w/ ref_obj_id set is valid
+ *   - true: regno of _last_ such arg reg is returned
+ *   - false: err if multiple args w/ ref_obj_id set are seen
+ */
+static int args_find_ref_obj_id_regno(struct bpf_verifier_env *env, struct bpf_reg_state *regs,
+				      u32 nargs, bool allow_multi)
+{
+	struct bpf_reg_state *reg;
+	u32 i, regno, found_regno = 0;
+
+	for (i = 0; i < nargs; i++) {
+		regno = i + 1;
+		reg = &regs[regno];
+
+		if (!reg->ref_obj_id)
+			continue;
+
+		if (!allow_multi && found_regno) {
+			verbose(env, "verifier internal error: more than one arg with ref_obj_id R%d %u %u\n",
+				regno, reg->ref_obj_id, regs[found_regno].ref_obj_id);
+			return -EFAULT;
+		}
+
+		found_regno = regno;
+	}
+
+	return found_regno;
+}
+
+/* Find the OBJ_RELEASE arg in helper func proto and return:
+ *   - regno of single OBJ_RELEASE arg
+ *   - 0 if no arg in the proto was OBJ_RELEASE
+ *   - Negative err if some invalid func proto state
+ */
+static int helper_proto_find_release_arg_regno(struct bpf_verifier_env *env,
+					       const struct bpf_func_proto *fn, u32 nargs)
+{
+	enum bpf_arg_type arg_type;
+	int i, release_regno = 0;
+
+	for (i = 0; i < nargs; i++) {
+		arg_type = fn->arg_type[i];
+
+		if (!arg_type_is_release(arg_type))
+			continue;
+
+		if (release_regno) {
+			verbose(env, "verifier internal error: more than one release argument\n");
+			return -EFAULT;
+		}
+
+		release_regno = i + BPF_REG_1;
+	}
+
+	return release_regno;
+}
+
 static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 			     int *insn_idx_p)
 {
 	enum bpf_prog_type prog_type = resolve_prog_type(env->prog);
+	int i, err, func_id, nargs, release_regno, ref_regno;
 	const struct bpf_func_proto *fn = NULL;
 	enum bpf_return_type ret_type;
 	enum bpf_type_flag ret_flag;
@@ -7710,7 +7756,6 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
 	struct bpf_call_arg_meta meta;
 	int insn_idx = *insn_idx_p;
 	bool changes_data;
-	int i, err, func_id;
 
 	/* find function prototype */
 	func_id = insn->imm;
@@ -7774,8 +7819,38 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
 	}
 
 	meta.func_id = func_id;
+	regs = cur_regs(env);
+
+	/* find actual arg count */
+	for (i = 0; i < MAX_BPF_FUNC_REG_ARGS; i++)
+		if (fn->arg_type[i] == ARG_DONTCARE)
+			break;
+	nargs = i;
+
+	release_regno = helper_proto_find_release_arg_regno(env, fn, nargs);
+	if (release_regno < 0)
+		return release_regno;
+
+	ref_regno = args_find_ref_obj_id_regno(env, regs, nargs, false);
+	if (ref_regno < 0)
+		return ref_regno;
+	else if (ref_regno > 0)
+		meta.ref_obj_id = regs[ref_regno].ref_obj_id;
+
+	if (release_regno > 0) {
+		if (!regs[release_regno].ref_obj_id &&
+		    !register_is_null(&regs[release_regno]) &&
+		    !arg_type_is_dynptr(fn->arg_type[release_regno - BPF_REG_1])) {
+			verbose(env, "R%d must be referenced when passed to release function\n",
+				release_regno);
+			return -EINVAL;
+		}
+
+		meta.release_regno = release_regno;
+	}
+
 	/* check args */
-	for (i = 0; i < MAX_BPF_FUNC_REG_ARGS; i++) {
+	for (i = 0; i < nargs; i++) {
 		err = check_func_arg(env, i, &meta, fn);
 		if (err)
 			return err;
@@ -7799,8 +7874,6 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
 			return err;
 	}
 
-	regs = cur_regs(env);
-
 	/* This can only be set for PTR_TO_STACK, as CONST_PTR_TO_DYNPTR cannot
 	 * be reinitialized by any dynptr helper. Hence, mark_stack_slots_dynptr
 	 * is safe to do directly.
@@ -8795,10 +8868,11 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
 static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
 {
 	const char *func_name = meta->func_name, *ref_tname;
+	struct bpf_reg_state *regs = cur_regs(env);
 	const struct btf *btf = meta->btf;
 	const struct btf_param *args;
 	u32 i, nargs;
-	int ret;
+	int ret, ref_regno;
 
 	args = (const struct btf_param *)(meta->func_proto + 1);
 	nargs = btf_type_vlen(meta->func_proto);
@@ -8808,17 +8882,31 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 		return -EINVAL;
 	}
 
+	ref_regno = args_find_ref_obj_id_regno(env, cur_regs(env), nargs, true);
+	if (ref_regno < 0) {
+		return ref_regno;
+	} else if (!ref_regno && is_kfunc_release(meta)) {
+		verbose(env, "release kernel function %s expects refcounted PTR_TO_BTF_ID\n",
+			func_name);
+		return -EINVAL;
+	}
+
+	meta->ref_obj_id = regs[ref_regno].ref_obj_id;
+	if (is_kfunc_release(meta))
+		meta->release_regno = ref_regno;
+
 	/* Check that BTF function arguments match actual types that the
 	 * verifier sees.
 	 */
 	for (i = 0; i < nargs; i++) {
-		struct bpf_reg_state *regs = cur_regs(env), *reg = &regs[i + 1];
 		const struct btf_type *t, *ref_t, *resolve_ret;
 		enum bpf_arg_type arg_type = ARG_DONTCARE;
 		u32 regno = i + 1, ref_id, type_size;
 		bool is_ret_buf_sz = false;
+		struct bpf_reg_state *reg;
 		int kf_arg_type;
 
+		reg = &regs[regno];
 		t = btf_type_skip_modifiers(btf, args[i].type, NULL);
 
 		if (is_kfunc_arg_ignore(btf, &args[i]))
@@ -8875,18 +8963,6 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 			return -EINVAL;
 		}
 
-		if (reg->ref_obj_id) {
-			if (is_kfunc_release(meta) && meta->ref_obj_id) {
-				verbose(env, "verifier internal error: more than one arg with ref_obj_id R%d %u %u\n",
-					regno, reg->ref_obj_id,
-					meta->ref_obj_id);
-				return -EFAULT;
-			}
-			meta->ref_obj_id = reg->ref_obj_id;
-			if (is_kfunc_release(meta))
-				meta->release_regno = regno;
-		}
-
 		ref_t = btf_type_skip_modifiers(btf, t->type, &ref_id);
 		ref_tname = btf_name_by_offset(btf, ref_t->name_off);
 
@@ -8929,7 +9005,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 			return -EFAULT;
 		}
 
-		if (is_kfunc_release(meta) && reg->ref_obj_id)
+		if (is_kfunc_release(meta) && regno == meta->release_regno)
 			arg_type |= OBJ_RELEASE;
 		ret = check_func_arg_reg_off(env, reg, regno, arg_type);
 		if (ret < 0)
@@ -9049,12 +9125,6 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 		}
 	}
 
-	if (is_kfunc_release(meta) && !meta->release_regno) {
-		verbose(env, "release kernel function %s expects refcounted PTR_TO_BTF_ID\n",
-			func_name);
-		return -EINVAL;
-	}
-
 	return 0;
 }
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs Dave Marchevsky
@ 2022-12-17  8:24 ` Dave Marchevsky
  2022-12-17  9:21   ` Dave Marchevsky
                     ` (3 more replies)
  2022-12-17  8:24 ` [PATCH v2 bpf-next 03/13] selftests/bpf: Update linked_list tests for " Dave Marchevsky
                   ` (10 subsequent siblings)
  12 siblings, 4 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

This patch introduces non-owning reference semantics to the verifier,
specifically linked_list API kfunc handling. release_on_unlock logic for
refs is refactored - with small functional changes - to implement these
semantics, and bpf_list_push_{front,back} are migrated to use them.

When a list node is pushed to a list, the program still has a pointer to
the node:

  n = bpf_obj_new(typeof(*n));

  bpf_spin_lock(&l);
  bpf_list_push_back(&l, n);
  /* n still points to the just-added node */
  bpf_spin_unlock(&l);

What the verifier considers n to be after the push, and thus what can be
done with n, are changed by this patch.

Common properties both before/after this patch:
  * After push, n is only a valid reference to the node until end of
    critical section
  * After push, n cannot be pushed to any list
  * After push, the program can read the node's fields using n

Before:
  * After push, n retains the ref_obj_id which it received on
    bpf_obj_new, but the associated bpf_reference_state's
    release_on_unlock field is set to true
    * release_on_unlock field and associated logic is used to implement
      "n is only a valid ref until end of critical section"
  * After push, n cannot be written to, the node must be removed from
    the list before writing to its fields
  * After push, n is marked PTR_UNTRUSTED

After:
  * After push, n's ref is released and ref_obj_id set to 0. The
    bpf_reg_state's non_owning_ref_lock struct is populated with the
    currently active lock
    * non_owning_ref_lock and logic is used to implement "n is only a
      valid ref until end of critical section"
  * n can be written to (except for special fields e.g. bpf_list_node,
    timer, ...)
  * No special type flag is added to n after push

Summary of specific implementation changes to achieve the above:

  * release_on_unlock field, ref_set_release_on_unlock helper, and logic
    to "release on unlock" based on that field are removed

  * The anonymous active_lock struct used by bpf_verifier_state is
    pulled out into a named struct bpf_active_lock.

  * A non_owning_ref_lock field of type bpf_active_lock is added to
    bpf_reg_state's PTR_TO_BTF_ID union

  * Helpers are added to use non_owning_ref_lock to implement non-owning
    ref semantics as described above
    * invalidate_non_owning_refs - helper to clobber all non-owning refs
      matching a particular bpf_active_lock identity. Replaces
      release_on_unlock logic in process_spin_lock.
    * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
      on current verifier state
    * ref_convert_owning_non_owning - convert owning reference w/
      specified ref_obj_id to non-owning references. Setup
      non_owning_ref_lock for each reg with that ref_obj_id and 0 out
      its ref_obj_id

  * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
    KF_RELEASE to indicate that the release arg reg should be converted
    to non-owning ref
    * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
      the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
      doing ref_convert_owning_non_owning on the ref first, which
      prevents the regs from being clobbered by 0ing out their
      ref_obj_ids. The bpf_reference_state itself is still released via
      release_reference as a result of the KF_RELEASE flag.
    * KF_RELEASE | KF_RELEASE_NON_OWN are added to
      bpf_list_push_{front,back}

After these changes, linked_list's "release on unlock" logic continues
to function as before, except for the semantic differences noted above.
The patch immediately following this one makes minor changes to
linked_list selftests to account for the differing behavior.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 include/linux/bpf.h          |   1 +
 include/linux/bpf_verifier.h |  39 ++++-----
 include/linux/btf.h          |  17 ++--
 kernel/bpf/helpers.c         |   4 +-
 kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
 5 files changed, 146 insertions(+), 79 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3de24cfb7a3d..f71571bf6adc 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -180,6 +180,7 @@ enum btf_field_type {
 	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
 	BPF_LIST_HEAD  = (1 << 4),
 	BPF_LIST_NODE  = (1 << 5),
+	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
 };
 
 struct btf_field_kptr {
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 53d175cbaa02..cb417ffbbb84 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -43,6 +43,22 @@ enum bpf_reg_liveness {
 	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
 };
 
+/* For every reg representing a map value or allocated object pointer,
+ * we consider the tuple of (ptr, id) for them to be unique in verifier
+ * context and conside them to not alias each other for the purposes of
+ * tracking lock state.
+ */
+struct bpf_active_lock {
+	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
+	 * there's no active lock held, and other fields have no
+	 * meaning. If non-NULL, it indicates that a lock is held and
+	 * id member has the reg->id of the register which can be >= 0.
+	 */
+	void *ptr;
+	/* This will be reg->id */
+	u32 id;
+};
+
 struct bpf_reg_state {
 	/* Ordering of fields matters.  See states_equal() */
 	enum bpf_reg_type type;
@@ -68,6 +84,7 @@ struct bpf_reg_state {
 		struct {
 			struct btf *btf;
 			u32 btf_id;
+			struct bpf_active_lock non_owning_ref_lock;
 		};
 
 		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
@@ -223,11 +240,6 @@ struct bpf_reference_state {
 	 * exiting a callback function.
 	 */
 	int callback_ref;
-	/* Mark the reference state to release the registers sharing the same id
-	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
-	 * safe to access inside the critical section).
-	 */
-	bool release_on_unlock;
 };
 
 /* state of the program:
@@ -328,21 +340,8 @@ struct bpf_verifier_state {
 	u32 branches;
 	u32 insn_idx;
 	u32 curframe;
-	/* For every reg representing a map value or allocated object pointer,
-	 * we consider the tuple of (ptr, id) for them to be unique in verifier
-	 * context and conside them to not alias each other for the purposes of
-	 * tracking lock state.
-	 */
-	struct {
-		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
-		 * there's no active lock held, and other fields have no
-		 * meaning. If non-NULL, it indicates that a lock is held and
-		 * id member has the reg->id of the register which can be >= 0.
-		 */
-		void *ptr;
-		/* This will be reg->id */
-		u32 id;
-	} active_lock;
+
+	struct bpf_active_lock active_lock;
 	bool speculative;
 	bool active_rcu_lock;
 
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 5f628f323442..8aee3f7f4248 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -15,10 +15,10 @@
 #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
 
 /* These need to be macros, as the expressions are used in assembler input */
-#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
-#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
-#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
-#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
+#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
+#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
+#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
+#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
 /* Trusted arguments are those which are guaranteed to be valid when passed to
  * the kfunc. It is used to enforce that pointers obtained from either acquire
  * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
@@ -67,10 +67,11 @@
  *	return 0;
  * }
  */
-#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
-#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
-#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
-#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
+#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
+#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
+#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
+#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
+#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
 
 /*
  * Return the name of the passed struct, if exists, or halt the build if for
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index af30c6cbd65d..e041409779c3 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
 #endif
 BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
-BTF_ID_FLAGS(func, bpf_list_push_front)
-BTF_ID_FLAGS(func, bpf_list_push_back)
+BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
+BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)
 BTF_ID_FLAGS(func, bpf_list_pop_front, KF_ACQUIRE | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_list_pop_back, KF_ACQUIRE | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 824e2242eae5..84b0660e2a76 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -190,6 +190,10 @@ struct bpf_verifier_stack_elem {
 
 static int acquire_reference_state(struct bpf_verifier_env *env, int insn_idx);
 static int release_reference(struct bpf_verifier_env *env, int ref_obj_id);
+static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
+				       struct bpf_active_lock *lock);
+static int ref_set_non_owning_lock(struct bpf_verifier_env *env,
+				   struct bpf_reg_state *reg);
 
 static bool bpf_map_ptr_poisoned(const struct bpf_insn_aux_data *aux)
 {
@@ -931,6 +935,9 @@ static void print_verifier_state(struct bpf_verifier_env *env,
 				verbose_a("id=%d", reg->id);
 			if (reg->ref_obj_id)
 				verbose_a("ref_obj_id=%d", reg->ref_obj_id);
+			if (reg->non_owning_ref_lock.ptr)
+				verbose_a("non_own_id=(%p,%d)", reg->non_owning_ref_lock.ptr,
+					  reg->non_owning_ref_lock.id);
 			if (t != SCALAR_VALUE)
 				verbose_a("off=%d", reg->off);
 			if (type_is_pkt_pointer(t))
@@ -4820,7 +4827,8 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
 			return -EACCES;
 		}
 
-		if (type_is_alloc(reg->type) && !reg->ref_obj_id) {
+		if (type_is_alloc(reg->type) && !reg->ref_obj_id &&
+		    !reg->non_owning_ref_lock.ptr) {
 			verbose(env, "verifier internal error: ref_obj_id for allocated object must be non-zero\n");
 			return -EFAULT;
 		}
@@ -5778,9 +5786,7 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
 			cur->active_lock.ptr = btf;
 		cur->active_lock.id = reg->id;
 	} else {
-		struct bpf_func_state *fstate = cur_func(env);
 		void *ptr;
-		int i;
 
 		if (map)
 			ptr = map;
@@ -5796,25 +5802,11 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
 			verbose(env, "bpf_spin_unlock of different lock\n");
 			return -EINVAL;
 		}
-		cur->active_lock.ptr = NULL;
-		cur->active_lock.id = 0;
 
-		for (i = fstate->acquired_refs - 1; i >= 0; i--) {
-			int err;
+		invalidate_non_owning_refs(env, &cur->active_lock);
 
-			/* Complain on error because this reference state cannot
-			 * be freed before this point, as bpf_spin_lock critical
-			 * section does not allow functions that release the
-			 * allocated object immediately.
-			 */
-			if (!fstate->refs[i].release_on_unlock)
-				continue;
-			err = release_reference(env, fstate->refs[i].id);
-			if (err) {
-				verbose(env, "failed to release release_on_unlock reference");
-				return err;
-			}
-		}
+		cur->active_lock.ptr = NULL;
+		cur->active_lock.id = 0;
 	}
 	return 0;
 }
@@ -6273,6 +6265,23 @@ static int check_reg_type(struct bpf_verifier_env *env, u32 regno,
 	return 0;
 }
 
+static struct btf_field *
+reg_find_field_offset(const struct bpf_reg_state *reg, s32 off, u32 fields)
+{
+	struct btf_field *field;
+	struct btf_record *rec;
+
+	rec = reg_btf_record(reg);
+	if (!reg)
+		return NULL;
+
+	field = btf_record_find(rec, off, fields);
+	if (!field)
+		return NULL;
+
+	return field;
+}
+
 int check_func_arg_reg_off(struct bpf_verifier_env *env,
 			   const struct bpf_reg_state *reg, int regno,
 			   enum bpf_arg_type arg_type)
@@ -6294,6 +6303,18 @@ int check_func_arg_reg_off(struct bpf_verifier_env *env,
 		 */
 		if (arg_type_is_dynptr(arg_type) && type == PTR_TO_STACK)
 			return 0;
+
+		if (type == (PTR_TO_BTF_ID | MEM_ALLOC) && reg->off) {
+			if (reg_find_field_offset(reg, reg->off, BPF_GRAPH_NODE_OR_ROOT))
+				return __check_ptr_off_reg(env, reg, regno, true);
+
+			verbose(env, "R%d must have zero offset when passed to release func\n",
+				regno);
+			verbose(env, "No graph node or root found at R%d type:%s off:%d\n", regno,
+				kernel_type_name(reg->btf, reg->btf_id), reg->off);
+			return -EINVAL;
+		}
+
 		/* Doing check_ptr_off_reg check for the offset will catch this
 		 * because fixed_off_ok is false, but checking here allows us
 		 * to give the user a better error message.
@@ -7055,6 +7076,20 @@ static int release_reference(struct bpf_verifier_env *env,
 	return 0;
 }
 
+static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
+				       struct bpf_active_lock *lock)
+{
+	struct bpf_func_state *unused;
+	struct bpf_reg_state *reg;
+
+	bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
+		if (reg->non_owning_ref_lock.ptr &&
+		    reg->non_owning_ref_lock.ptr == lock->ptr &&
+		    reg->non_owning_ref_lock.id == lock->id)
+			__mark_reg_unknown(env, reg);
+	}));
+}
+
 static void clear_caller_saved_regs(struct bpf_verifier_env *env,
 				    struct bpf_reg_state *regs)
 {
@@ -8266,6 +8301,11 @@ static bool is_kfunc_release(struct bpf_kfunc_call_arg_meta *meta)
 	return meta->kfunc_flags & KF_RELEASE;
 }
 
+static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
+{
+	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
+}
+
 static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
 {
 	return meta->kfunc_flags & KF_TRUSTED_ARGS;
@@ -8651,38 +8691,55 @@ static int process_kf_arg_ptr_to_kptr(struct bpf_verifier_env *env,
 	return 0;
 }
 
-static int ref_set_release_on_unlock(struct bpf_verifier_env *env, u32 ref_obj_id)
+static int ref_set_non_owning_lock(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
 {
-	struct bpf_func_state *state = cur_func(env);
+	struct bpf_verifier_state *state = env->cur_state;
+
+	if (!state->active_lock.ptr) {
+		verbose(env, "verifier internal error: ref_set_non_owning_lock w/o active lock\n");
+		return -EFAULT;
+	}
+
+	if (reg->non_owning_ref_lock.ptr) {
+		verbose(env, "verifier internal error: non_owning_ref_lock already set\n");
+		return -EFAULT;
+	}
+
+	reg->non_owning_ref_lock.id = state->active_lock.id;
+	reg->non_owning_ref_lock.ptr = state->active_lock.ptr;
+	return 0;
+}
+
+static int ref_convert_owning_non_owning(struct bpf_verifier_env *env, u32 ref_obj_id)
+{
+	struct bpf_func_state *state, *unused;
 	struct bpf_reg_state *reg;
 	int i;
 
-	/* bpf_spin_lock only allows calling list_push and list_pop, no BPF
-	 * subprogs, no global functions. This means that the references would
-	 * not be released inside the critical section but they may be added to
-	 * the reference state, and the acquired_refs are never copied out for a
-	 * different frame as BPF to BPF calls don't work in bpf_spin_lock
-	 * critical sections.
-	 */
+	state = cur_func(env);
+
 	if (!ref_obj_id) {
-		verbose(env, "verifier internal error: ref_obj_id is zero for release_on_unlock\n");
+		verbose(env, "verifier internal error: ref_obj_id is zero for "
+			     "owning -> non-owning conversion\n");
 		return -EFAULT;
 	}
+
 	for (i = 0; i < state->acquired_refs; i++) {
-		if (state->refs[i].id == ref_obj_id) {
-			if (state->refs[i].release_on_unlock) {
-				verbose(env, "verifier internal error: expected false release_on_unlock");
-				return -EFAULT;
+		if (state->refs[i].id != ref_obj_id)
+			continue;
+
+		/* Clear ref_obj_id here so release_reference doesn't clobber
+		 * the whole reg
+		 */
+		bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
+			if (reg->ref_obj_id == ref_obj_id) {
+				reg->ref_obj_id = 0;
+				ref_set_non_owning_lock(env, reg);
 			}
-			state->refs[i].release_on_unlock = true;
-			/* Now mark everyone sharing same ref_obj_id as untrusted */
-			bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
-				if (reg->ref_obj_id == ref_obj_id)
-					reg->type |= PTR_UNTRUSTED;
-			}));
-			return 0;
-		}
+		}));
+		return 0;
 	}
+
 	verbose(env, "verifier internal error: ref state missing for ref_obj_id\n");
 	return -EFAULT;
 }
@@ -8817,7 +8874,6 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
 {
 	const struct btf_type *et, *t;
 	struct btf_field *field;
-	struct btf_record *rec;
 	u32 list_node_off;
 
 	if (meta->btf != btf_vmlinux ||
@@ -8834,9 +8890,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
 		return -EINVAL;
 	}
 
-	rec = reg_btf_record(reg);
 	list_node_off = reg->off + reg->var_off.value;
-	field = btf_record_find(rec, list_node_off, BPF_LIST_NODE);
+	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
 	if (!field || field->offset != list_node_off) {
 		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
 		return -EINVAL;
@@ -8861,8 +8916,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
 			btf_name_by_offset(field->list_head.btf, et->name_off));
 		return -EINVAL;
 	}
-	/* Set arg#1 for expiration after unlock */
-	return ref_set_release_on_unlock(env, reg->ref_obj_id);
+
+	return 0;
 }
 
 static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
@@ -9132,11 +9187,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 			    int *insn_idx_p)
 {
 	const struct btf_type *t, *func, *func_proto, *ptr_type;
+	u32 i, nargs, func_id, ptr_type_id, release_ref_obj_id;
 	struct bpf_reg_state *regs = cur_regs(env);
 	const char *func_name, *ptr_type_name;
 	bool sleepable, rcu_lock, rcu_unlock;
 	struct bpf_kfunc_call_arg_meta meta;
-	u32 i, nargs, func_id, ptr_type_id;
 	int err, insn_idx = *insn_idx_p;
 	const struct btf_param *args;
 	const struct btf_type *ret_t;
@@ -9223,7 +9278,18 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 	 * PTR_TO_BTF_ID in bpf_kfunc_arg_meta, do the release now.
 	 */
 	if (meta.release_regno) {
-		err = release_reference(env, regs[meta.release_regno].ref_obj_id);
+		err = 0;
+		release_ref_obj_id = regs[meta.release_regno].ref_obj_id;
+
+		if (is_kfunc_release_non_own(&meta))
+			err = ref_convert_owning_non_owning(env, release_ref_obj_id);
+		if (err) {
+			verbose(env, "kfunc %s#%d conversion of owning ref to non-owning failed\n",
+				func_name, func_id);
+			return err;
+		}
+
+		err = release_reference(env, release_ref_obj_id);
 		if (err) {
 			verbose(env, "kfunc %s#%d reference has not been acquired before\n",
 				func_name, func_id);
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 03/13] selftests/bpf: Update linked_list tests for non-owning ref semantics
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
@ 2022-12-17  8:24 ` Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 04/13] bpf: rename list_head -> graph_root in field info types Dave Marchevsky
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

Current linked_list semantics for release_on_unlock node refs are almost
exactly the same as newly-introduced "non-owning reference" concept. The
only difference: writes to a release_on_unlock node ref are not allowed,
while writes to non-owning reference pointees are.

As a result the linked_list "write after push" failure tests are no
longer scenarios that should fail.

The test##_missing_lock_##op and test##_incorrect_lock_##op
macro-generated failure tests need to have a valid node argument in
order to have the same error output as before. Otherwise verification
will fail early and the expected error output won't be seen.

Some other tests have minor changes in error output, but fail for the
same reason.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 .../selftests/bpf/prog_tests/linked_list.c    |  10 +-
 .../testing/selftests/bpf/progs/linked_list.c |   2 +-
 .../selftests/bpf/progs/linked_list_fail.c    | 100 +++++++++++-------
 3 files changed, 68 insertions(+), 44 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/linked_list.c b/tools/testing/selftests/bpf/prog_tests/linked_list.c
index 9a7d4c47af63..a8091a0c0831 100644
--- a/tools/testing/selftests/bpf/prog_tests/linked_list.c
+++ b/tools/testing/selftests/bpf/prog_tests/linked_list.c
@@ -78,18 +78,18 @@ static struct {
 	{ "direct_write_head", "direct access to bpf_list_head is disallowed" },
 	{ "direct_read_node", "direct access to bpf_list_node is disallowed" },
 	{ "direct_write_node", "direct access to bpf_list_node is disallowed" },
-	{ "write_after_push_front", "only read is supported" },
-	{ "write_after_push_back", "only read is supported" },
 	{ "use_after_unlock_push_front", "invalid mem access 'scalar'" },
 	{ "use_after_unlock_push_back", "invalid mem access 'scalar'" },
-	{ "double_push_front", "arg#1 expected pointer to allocated object" },
-	{ "double_push_back", "arg#1 expected pointer to allocated object" },
+	{ "double_push_front",
+	  "release kernel function bpf_list_push_front expects refcounted PTR_TO_BTF_ID" },
+	{ "double_push_back",
+	  "release kernel function bpf_list_push_back expects refcounted PTR_TO_BTF_ID" },
 	{ "no_node_value_type", "bpf_list_node not found at offset=0" },
 	{ "incorrect_value_type",
 	  "operation on bpf_list_head expects arg#1 bpf_list_node at offset=0 in struct foo, "
 	  "but arg is at offset=0 in struct bar" },
 	{ "incorrect_node_var_off", "variable ptr_ access var_off=(0x0; 0xffffffff) disallowed" },
-	{ "incorrect_node_off1", "bpf_list_node not found at offset=1" },
+	{ "incorrect_node_off1", "No graph node or root found at R2 type:foo off:1" },
 	{ "incorrect_node_off2", "arg#1 offset=40, but expected bpf_list_node at offset=0 in struct foo" },
 	{ "no_head_type", "bpf_list_head not found at offset=0" },
 	{ "incorrect_head_var_off1", "R1 doesn't have constant offset" },
diff --git a/tools/testing/selftests/bpf/progs/linked_list.c b/tools/testing/selftests/bpf/progs/linked_list.c
index 4ad88da5cda2..4fa4a9b01bde 100644
--- a/tools/testing/selftests/bpf/progs/linked_list.c
+++ b/tools/testing/selftests/bpf/progs/linked_list.c
@@ -260,7 +260,7 @@ int test_list_push_pop_multiple(struct bpf_spin_lock *lock, struct bpf_list_head
 {
 	int ret;
 
-	ret = list_push_pop_multiple(lock ,head, false);
+	ret = list_push_pop_multiple(lock, head, false);
 	if (ret)
 		return ret;
 	return list_push_pop_multiple(lock, head, true);
diff --git a/tools/testing/selftests/bpf/progs/linked_list_fail.c b/tools/testing/selftests/bpf/progs/linked_list_fail.c
index 1d9017240e19..69cdc07cba13 100644
--- a/tools/testing/selftests/bpf/progs/linked_list_fail.c
+++ b/tools/testing/selftests/bpf/progs/linked_list_fail.c
@@ -54,28 +54,44 @@
 		return 0;                                   \
 	}
 
-CHECK(kptr, push_front, &f->head);
-CHECK(kptr, push_back, &f->head);
 CHECK(kptr, pop_front, &f->head);
 CHECK(kptr, pop_back, &f->head);
 
-CHECK(global, push_front, &ghead);
-CHECK(global, push_back, &ghead);
 CHECK(global, pop_front, &ghead);
 CHECK(global, pop_back, &ghead);
 
-CHECK(map, push_front, &v->head);
-CHECK(map, push_back, &v->head);
 CHECK(map, pop_front, &v->head);
 CHECK(map, pop_back, &v->head);
 
-CHECK(inner_map, push_front, &iv->head);
-CHECK(inner_map, push_back, &iv->head);
 CHECK(inner_map, pop_front, &iv->head);
 CHECK(inner_map, pop_back, &iv->head);
 
 #undef CHECK
 
+#define CHECK(test, op, hexpr, nexpr)					\
+	SEC("?tc")							\
+	int test##_missing_lock_##op(void *ctx)				\
+	{								\
+		INIT;							\
+		void (*p)(void *, void *) = (void *)&bpf_list_##op;	\
+		p(hexpr, nexpr);					\
+		return 0;						\
+	}
+
+CHECK(kptr, push_front, &f->head, b);
+CHECK(kptr, push_back, &f->head, b);
+
+CHECK(global, push_front, &ghead, f);
+CHECK(global, push_back, &ghead, f);
+
+CHECK(map, push_front, &v->head, f);
+CHECK(map, push_back, &v->head, f);
+
+CHECK(inner_map, push_front, &iv->head, f);
+CHECK(inner_map, push_back, &iv->head, f);
+
+#undef CHECK
+
 #define CHECK(test, op, lexpr, hexpr)                       \
 	SEC("?tc")                                          \
 	int test##_incorrect_lock_##op(void *ctx)           \
@@ -108,11 +124,47 @@ CHECK(inner_map, pop_back, &iv->head);
 	CHECK(inner_map_global, op, &iv->lock, &ghead);        \
 	CHECK(inner_map_map, op, &iv->lock, &v->head);
 
-CHECK_OP(push_front);
-CHECK_OP(push_back);
 CHECK_OP(pop_front);
 CHECK_OP(pop_back);
 
+#undef CHECK
+#undef CHECK_OP
+
+#define CHECK(test, op, lexpr, hexpr, nexpr)				\
+	SEC("?tc")							\
+	int test##_incorrect_lock_##op(void *ctx)			\
+	{								\
+		INIT;							\
+		void (*p)(void *, void*) = (void *)&bpf_list_##op;	\
+		bpf_spin_lock(lexpr);					\
+		p(hexpr, nexpr);					\
+		return 0;						\
+	}
+
+#define CHECK_OP(op)							\
+	CHECK(kptr_kptr, op, &f1->lock, &f2->head, b);			\
+	CHECK(kptr_global, op, &f1->lock, &ghead, f);			\
+	CHECK(kptr_map, op, &f1->lock, &v->head, f);			\
+	CHECK(kptr_inner_map, op, &f1->lock, &iv->head, f);		\
+									\
+	CHECK(global_global, op, &glock2, &ghead, f);			\
+	CHECK(global_kptr, op, &glock, &f1->head, b);			\
+	CHECK(global_map, op, &glock, &v->head, f);			\
+	CHECK(global_inner_map, op, &glock, &iv->head, f);		\
+									\
+	CHECK(map_map, op, &v->lock, &v2->head, f);			\
+	CHECK(map_kptr, op, &v->lock, &f2->head, b);			\
+	CHECK(map_global, op, &v->lock, &ghead, f);			\
+	CHECK(map_inner_map, op, &v->lock, &iv->head, f);		\
+									\
+	CHECK(inner_map_inner_map, op, &iv->lock, &iv2->head, f);	\
+	CHECK(inner_map_kptr, op, &iv->lock, &f2->head, b);		\
+	CHECK(inner_map_global, op, &iv->lock, &ghead, f);		\
+	CHECK(inner_map_map, op, &iv->lock, &v->head, f);
+
+CHECK_OP(push_front);
+CHECK_OP(push_back);
+
 #undef CHECK
 #undef CHECK_OP
 #undef INIT
@@ -303,34 +355,6 @@ int direct_write_node(void *ctx)
 	return 0;
 }
 
-static __always_inline
-int write_after_op(void (*push_op)(void *head, void *node))
-{
-	struct foo *f;
-
-	f = bpf_obj_new(typeof(*f));
-	if (!f)
-		return 0;
-	bpf_spin_lock(&glock);
-	push_op(&ghead, &f->node);
-	f->data = 42;
-	bpf_spin_unlock(&glock);
-
-	return 0;
-}
-
-SEC("?tc")
-int write_after_push_front(void *ctx)
-{
-	return write_after_op((void *)bpf_list_push_front);
-}
-
-SEC("?tc")
-int write_after_push_back(void *ctx)
-{
-	return write_after_op((void *)bpf_list_push_back);
-}
-
 static __always_inline
 int use_after_unlock(void (*op)(void *head, void *node))
 {
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 04/13] bpf: rename list_head -> graph_root in field info types
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (2 preceding siblings ...)
  2022-12-17  8:24 ` [PATCH v2 bpf-next 03/13] selftests/bpf: Update linked_list tests for " Dave Marchevsky
@ 2022-12-17  8:24 ` Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 05/13] bpf: Add basic bpf_rb_{root,node} support Dave Marchevsky
                   ` (8 subsequent siblings)
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

Many of the structs recently added to track field info for linked-list
head are useful as-is for rbtree root. So let's do a mechanical renaming
of list_head-related types and fields:

include/linux/bpf.h:
  struct btf_field_list_head -> struct btf_field_graph_root
  list_head -> graph_root in struct btf_field union
kernel/bpf/btf.c:
  list_head -> graph_root in struct btf_field_info

This is a nonfunctional change, functionality to actually use these
fields for rbtree will be added in further patches.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 include/linux/bpf.h   |  4 ++--
 kernel/bpf/btf.c      | 21 +++++++++++----------
 kernel/bpf/helpers.c  |  4 ++--
 kernel/bpf/verifier.c | 21 +++++++++++----------
 4 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index f71571bf6adc..3b49c11729b0 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -190,7 +190,7 @@ struct btf_field_kptr {
 	u32 btf_id;
 };
 
-struct btf_field_list_head {
+struct btf_field_graph_root {
 	struct btf *btf;
 	u32 value_btf_id;
 	u32 node_offset;
@@ -202,7 +202,7 @@ struct btf_field {
 	enum btf_field_type type;
 	union {
 		struct btf_field_kptr kptr;
-		struct btf_field_list_head list_head;
+		struct btf_field_graph_root graph_root;
 	};
 };
 
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index f7dd8af06413..578cee398550 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -3228,7 +3228,7 @@ struct btf_field_info {
 		struct {
 			const char *node_name;
 			u32 value_btf_id;
-		} list_head;
+		} graph_root;
 	};
 };
 
@@ -3335,8 +3335,8 @@ static int btf_find_list_head(const struct btf *btf, const struct btf_type *pt,
 		return -EINVAL;
 	info->type = BPF_LIST_HEAD;
 	info->off = off;
-	info->list_head.value_btf_id = id;
-	info->list_head.node_name = list_node;
+	info->graph_root.value_btf_id = id;
+	info->graph_root.node_name = list_node;
 	return BTF_FIELD_FOUND;
 }
 
@@ -3604,13 +3604,14 @@ static int btf_parse_list_head(const struct btf *btf, struct btf_field *field,
 	u32 offset;
 	int i;
 
-	t = btf_type_by_id(btf, info->list_head.value_btf_id);
+	t = btf_type_by_id(btf, info->graph_root.value_btf_id);
 	/* We've already checked that value_btf_id is a struct type. We
 	 * just need to figure out the offset of the list_node, and
 	 * verify its type.
 	 */
 	for_each_member(i, t, member) {
-		if (strcmp(info->list_head.node_name, __btf_name_by_offset(btf, member->name_off)))
+		if (strcmp(info->graph_root.node_name,
+			   __btf_name_by_offset(btf, member->name_off)))
 			continue;
 		/* Invalid BTF, two members with same name */
 		if (n)
@@ -3627,9 +3628,9 @@ static int btf_parse_list_head(const struct btf *btf, struct btf_field *field,
 		if (offset % __alignof__(struct bpf_list_node))
 			return -EINVAL;
 
-		field->list_head.btf = (struct btf *)btf;
-		field->list_head.value_btf_id = info->list_head.value_btf_id;
-		field->list_head.node_offset = offset;
+		field->graph_root.btf = (struct btf *)btf;
+		field->graph_root.value_btf_id = info->graph_root.value_btf_id;
+		field->graph_root.node_offset = offset;
 	}
 	if (!n)
 		return -ENOENT;
@@ -3736,11 +3737,11 @@ int btf_check_and_fixup_fields(const struct btf *btf, struct btf_record *rec)
 
 		if (!(rec->fields[i].type & BPF_LIST_HEAD))
 			continue;
-		btf_id = rec->fields[i].list_head.value_btf_id;
+		btf_id = rec->fields[i].graph_root.value_btf_id;
 		meta = btf_find_struct_meta(btf, btf_id);
 		if (!meta)
 			return -EFAULT;
-		rec->fields[i].list_head.value_rec = meta->record;
+		rec->fields[i].graph_root.value_rec = meta->record;
 
 		if (!(rec->field_mask & BPF_LIST_NODE))
 			continue;
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index e041409779c3..1df87af6919e 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1745,12 +1745,12 @@ void bpf_list_head_free(const struct btf_field *field, void *list_head,
 	while (head != orig_head) {
 		void *obj = head;
 
-		obj -= field->list_head.node_offset;
+		obj -= field->graph_root.node_offset;
 		head = head->next;
 		/* The contained type can also have resources, including a
 		 * bpf_list_head which needs to be freed.
 		 */
-		bpf_obj_free_fields(field->list_head.value_rec, obj);
+		bpf_obj_free_fields(field->graph_root.value_rec, obj);
 		/* bpf_mem_free requires migrate_disable(), since we can be
 		 * called from map free path as well apart from BPF program (as
 		 * part of map ops doing bpf_obj_free_fields).
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 84b0660e2a76..c914230beea7 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -8899,21 +8899,22 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
 
 	field = meta->arg_list_head.field;
 
-	et = btf_type_by_id(field->list_head.btf, field->list_head.value_btf_id);
+	et = btf_type_by_id(field->graph_root.btf, field->graph_root.value_btf_id);
 	t = btf_type_by_id(reg->btf, reg->btf_id);
-	if (!btf_struct_ids_match(&env->log, reg->btf, reg->btf_id, 0, field->list_head.btf,
-				  field->list_head.value_btf_id, true)) {
+	if (!btf_struct_ids_match(&env->log, reg->btf, reg->btf_id, 0, field->graph_root.btf,
+				  field->graph_root.value_btf_id, true)) {
 		verbose(env, "operation on bpf_list_head expects arg#1 bpf_list_node at offset=%d "
 			"in struct %s, but arg is at offset=%d in struct %s\n",
-			field->list_head.node_offset, btf_name_by_offset(field->list_head.btf, et->name_off),
+			field->graph_root.node_offset,
+			btf_name_by_offset(field->graph_root.btf, et->name_off),
 			list_node_off, btf_name_by_offset(reg->btf, t->name_off));
 		return -EINVAL;
 	}
 
-	if (list_node_off != field->list_head.node_offset) {
+	if (list_node_off != field->graph_root.node_offset) {
 		verbose(env, "arg#1 offset=%d, but expected bpf_list_node at offset=%d in struct %s\n",
-			list_node_off, field->list_head.node_offset,
-			btf_name_by_offset(field->list_head.btf, et->name_off));
+			list_node_off, field->graph_root.node_offset,
+			btf_name_by_offset(field->graph_root.btf, et->name_off));
 		return -EINVAL;
 	}
 
@@ -9363,9 +9364,9 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 
 				mark_reg_known_zero(env, regs, BPF_REG_0);
 				regs[BPF_REG_0].type = PTR_TO_BTF_ID | MEM_ALLOC;
-				regs[BPF_REG_0].btf = field->list_head.btf;
-				regs[BPF_REG_0].btf_id = field->list_head.value_btf_id;
-				regs[BPF_REG_0].off = field->list_head.node_offset;
+				regs[BPF_REG_0].btf = field->graph_root.btf;
+				regs[BPF_REG_0].btf_id = field->graph_root.value_btf_id;
+				regs[BPF_REG_0].off = field->graph_root.node_offset;
 			} else if (meta.func_id == special_kfunc_list[KF_bpf_cast_to_kern_ctx]) {
 				mark_reg_known_zero(env, regs, BPF_REG_0);
 				regs[BPF_REG_0].type = PTR_TO_BTF_ID | PTR_TRUSTED;
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 05/13] bpf: Add basic bpf_rb_{root,node} support
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (3 preceding siblings ...)
  2022-12-17  8:24 ` [PATCH v2 bpf-next 04/13] bpf: rename list_head -> graph_root in field info types Dave Marchevsky
@ 2022-12-17  8:24 ` Dave Marchevsky
  2022-12-17  8:24 ` [PATCH v2 bpf-next 06/13] bpf: Add bpf_rbtree_{add,remove,first} kfuncs Dave Marchevsky
                   ` (7 subsequent siblings)
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

This patch adds special BPF_RB_{ROOT,NODE} btf_field_types similar to
BPF_LIST_{HEAD,NODE}, adds the necessary plumbing to detect the new
types, and adds bpf_rb_root_free function for freeing bpf_rb_root in
map_values.

structs bpf_rb_root and bpf_rb_node are opaque types meant to
obscure structs rb_root_cached rb_node, respectively.

btf_struct_access will prevent BPF programs from touching these special
fields automatically now that they're recognized.

btf_check_and_fixup_fields now groups list_head and rb_root together as
"graph root" fields and {list,rb}_node as "graph node", and does same
ownership cycle checking as before. Note that this function does _not_
prevent ownership type mixups (e.g. rb_root owning list_node) - that's
handled by btf_parse_graph_root.

After this patch, a bpf program can have a struct bpf_rb_root in a
map_value, but not add anything to nor do anything useful with it.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 include/linux/bpf.h                           |  20 ++-
 include/uapi/linux/bpf.h                      |  11 ++
 kernel/bpf/btf.c                              | 162 ++++++++++++------
 kernel/bpf/helpers.c                          |  40 +++++
 kernel/bpf/syscall.c                          |  28 ++-
 kernel/bpf/verifier.c                         |   5 +-
 tools/include/uapi/linux/bpf.h                |  11 ++
 .../selftests/bpf/prog_tests/linked_list.c    |  12 +-
 8 files changed, 216 insertions(+), 73 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3b49c11729b0..01ada7e04fa7 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -180,7 +180,10 @@ enum btf_field_type {
 	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
 	BPF_LIST_HEAD  = (1 << 4),
 	BPF_LIST_NODE  = (1 << 5),
-	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
+	BPF_RB_ROOT    = (1 << 6),
+	BPF_RB_NODE    = (1 << 7),
+	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD |
+				 BPF_RB_NODE | BPF_RB_ROOT,
 };
 
 struct btf_field_kptr {
@@ -284,6 +287,10 @@ static inline const char *btf_field_type_name(enum btf_field_type type)
 		return "bpf_list_head";
 	case BPF_LIST_NODE:
 		return "bpf_list_node";
+	case BPF_RB_ROOT:
+		return "bpf_rb_root";
+	case BPF_RB_NODE:
+		return "bpf_rb_node";
 	default:
 		WARN_ON_ONCE(1);
 		return "unknown";
@@ -304,6 +311,10 @@ static inline u32 btf_field_type_size(enum btf_field_type type)
 		return sizeof(struct bpf_list_head);
 	case BPF_LIST_NODE:
 		return sizeof(struct bpf_list_node);
+	case BPF_RB_ROOT:
+		return sizeof(struct bpf_rb_root);
+	case BPF_RB_NODE:
+		return sizeof(struct bpf_rb_node);
 	default:
 		WARN_ON_ONCE(1);
 		return 0;
@@ -324,6 +335,10 @@ static inline u32 btf_field_type_align(enum btf_field_type type)
 		return __alignof__(struct bpf_list_head);
 	case BPF_LIST_NODE:
 		return __alignof__(struct bpf_list_node);
+	case BPF_RB_ROOT:
+		return __alignof__(struct bpf_rb_root);
+	case BPF_RB_NODE:
+		return __alignof__(struct bpf_rb_node);
 	default:
 		WARN_ON_ONCE(1);
 		return 0;
@@ -434,6 +449,9 @@ void copy_map_value_locked(struct bpf_map *map, void *dst, void *src,
 void bpf_timer_cancel_and_free(void *timer);
 void bpf_list_head_free(const struct btf_field *field, void *list_head,
 			struct bpf_spin_lock *spin_lock);
+void bpf_rb_root_free(const struct btf_field *field, void *rb_root,
+		      struct bpf_spin_lock *spin_lock);
+
 
 int bpf_obj_name_cpy(char *dst, const char *src, unsigned int size);
 
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 464ca3f01fe7..bd260134c420 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -6901,6 +6901,17 @@ struct bpf_list_node {
 	__u64 :64;
 } __attribute__((aligned(8)));
 
+struct bpf_rb_root {
+	__u64 :64;
+	__u64 :64;
+} __attribute__((aligned(8)));
+
+struct bpf_rb_node {
+	__u64 :64;
+	__u64 :64;
+	__u64 :64;
+} __attribute__((aligned(8)));
+
 struct bpf_sysctl {
 	__u32	write;		/* Sysctl is being read (= 0) or written (= 1).
 				 * Allows 1,2,4-byte read, but no write.
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 578cee398550..830bf2a58402 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -3305,12 +3305,14 @@ static const char *btf_find_decl_tag_value(const struct btf *btf,
 	return NULL;
 }
 
-static int btf_find_list_head(const struct btf *btf, const struct btf_type *pt,
-			      const struct btf_type *t, int comp_idx,
-			      u32 off, int sz, struct btf_field_info *info)
+static int
+btf_find_graph_root(const struct btf *btf, const struct btf_type *pt,
+		    const struct btf_type *t, int comp_idx, u32 off,
+		    int sz, struct btf_field_info *info,
+		    enum btf_field_type head_type)
 {
+	const char *node_field_name;
 	const char *value_type;
-	const char *list_node;
 	s32 id;
 
 	if (!__btf_type_is_struct(t))
@@ -3320,26 +3322,32 @@ static int btf_find_list_head(const struct btf *btf, const struct btf_type *pt,
 	value_type = btf_find_decl_tag_value(btf, pt, comp_idx, "contains:");
 	if (!value_type)
 		return -EINVAL;
-	list_node = strstr(value_type, ":");
-	if (!list_node)
+	node_field_name = strstr(value_type, ":");
+	if (!node_field_name)
 		return -EINVAL;
-	value_type = kstrndup(value_type, list_node - value_type, GFP_KERNEL | __GFP_NOWARN);
+	value_type = kstrndup(value_type, node_field_name - value_type, GFP_KERNEL | __GFP_NOWARN);
 	if (!value_type)
 		return -ENOMEM;
 	id = btf_find_by_name_kind(btf, value_type, BTF_KIND_STRUCT);
 	kfree(value_type);
 	if (id < 0)
 		return id;
-	list_node++;
-	if (str_is_empty(list_node))
+	node_field_name++;
+	if (str_is_empty(node_field_name))
 		return -EINVAL;
-	info->type = BPF_LIST_HEAD;
+	info->type = head_type;
 	info->off = off;
 	info->graph_root.value_btf_id = id;
-	info->graph_root.node_name = list_node;
+	info->graph_root.node_name = node_field_name;
 	return BTF_FIELD_FOUND;
 }
 
+#define field_mask_test_name(field_type, field_type_str) \
+	if (field_mask & field_type && !strcmp(name, field_type_str)) { \
+		type = field_type;					\
+		goto end;						\
+	}
+
 static int btf_get_field_type(const char *name, u32 field_mask, u32 *seen_mask,
 			      int *align, int *sz)
 {
@@ -3363,18 +3371,11 @@ static int btf_get_field_type(const char *name, u32 field_mask, u32 *seen_mask,
 			goto end;
 		}
 	}
-	if (field_mask & BPF_LIST_HEAD) {
-		if (!strcmp(name, "bpf_list_head")) {
-			type = BPF_LIST_HEAD;
-			goto end;
-		}
-	}
-	if (field_mask & BPF_LIST_NODE) {
-		if (!strcmp(name, "bpf_list_node")) {
-			type = BPF_LIST_NODE;
-			goto end;
-		}
-	}
+	field_mask_test_name(BPF_LIST_HEAD, "bpf_list_head");
+	field_mask_test_name(BPF_LIST_NODE, "bpf_list_node");
+	field_mask_test_name(BPF_RB_ROOT,   "bpf_rb_root");
+	field_mask_test_name(BPF_RB_NODE,   "bpf_rb_node");
+
 	/* Only return BPF_KPTR when all other types with matchable names fail */
 	if (field_mask & BPF_KPTR) {
 		type = BPF_KPTR_REF;
@@ -3387,6 +3388,8 @@ static int btf_get_field_type(const char *name, u32 field_mask, u32 *seen_mask,
 	return type;
 }
 
+#undef field_mask_test_name
+
 static int btf_find_struct_field(const struct btf *btf,
 				 const struct btf_type *t, u32 field_mask,
 				 struct btf_field_info *info, int info_cnt)
@@ -3419,6 +3422,7 @@ static int btf_find_struct_field(const struct btf *btf,
 		case BPF_SPIN_LOCK:
 		case BPF_TIMER:
 		case BPF_LIST_NODE:
+		case BPF_RB_NODE:
 			ret = btf_find_struct(btf, member_type, off, sz, field_type,
 					      idx < info_cnt ? &info[idx] : &tmp);
 			if (ret < 0)
@@ -3432,8 +3436,11 @@ static int btf_find_struct_field(const struct btf *btf,
 				return ret;
 			break;
 		case BPF_LIST_HEAD:
-			ret = btf_find_list_head(btf, t, member_type, i, off, sz,
-						 idx < info_cnt ? &info[idx] : &tmp);
+		case BPF_RB_ROOT:
+			ret = btf_find_graph_root(btf, t, member_type,
+						  i, off, sz,
+						  idx < info_cnt ? &info[idx] : &tmp,
+						  field_type);
 			if (ret < 0)
 				return ret;
 			break;
@@ -3480,6 +3487,7 @@ static int btf_find_datasec_var(const struct btf *btf, const struct btf_type *t,
 		case BPF_SPIN_LOCK:
 		case BPF_TIMER:
 		case BPF_LIST_NODE:
+		case BPF_RB_NODE:
 			ret = btf_find_struct(btf, var_type, off, sz, field_type,
 					      idx < info_cnt ? &info[idx] : &tmp);
 			if (ret < 0)
@@ -3493,8 +3501,11 @@ static int btf_find_datasec_var(const struct btf *btf, const struct btf_type *t,
 				return ret;
 			break;
 		case BPF_LIST_HEAD:
-			ret = btf_find_list_head(btf, var, var_type, -1, off, sz,
-						 idx < info_cnt ? &info[idx] : &tmp);
+		case BPF_RB_ROOT:
+			ret = btf_find_graph_root(btf, var, var_type,
+						  -1, off, sz,
+						  idx < info_cnt ? &info[idx] : &tmp,
+						  field_type);
 			if (ret < 0)
 				return ret;
 			break;
@@ -3596,8 +3607,11 @@ static int btf_parse_kptr(const struct btf *btf, struct btf_field *field,
 	return ret;
 }
 
-static int btf_parse_list_head(const struct btf *btf, struct btf_field *field,
-			       struct btf_field_info *info)
+static int btf_parse_graph_root(const struct btf *btf,
+				struct btf_field *field,
+				struct btf_field_info *info,
+				const char *node_type_name,
+				size_t node_type_align)
 {
 	const struct btf_type *t, *n = NULL;
 	const struct btf_member *member;
@@ -3619,13 +3633,13 @@ static int btf_parse_list_head(const struct btf *btf, struct btf_field *field,
 		n = btf_type_by_id(btf, member->type);
 		if (!__btf_type_is_struct(n))
 			return -EINVAL;
-		if (strcmp("bpf_list_node", __btf_name_by_offset(btf, n->name_off)))
+		if (strcmp(node_type_name, __btf_name_by_offset(btf, n->name_off)))
 			return -EINVAL;
 		offset = __btf_member_bit_offset(n, member);
 		if (offset % 8)
 			return -EINVAL;
 		offset /= 8;
-		if (offset % __alignof__(struct bpf_list_node))
+		if (offset % node_type_align)
 			return -EINVAL;
 
 		field->graph_root.btf = (struct btf *)btf;
@@ -3637,6 +3651,20 @@ static int btf_parse_list_head(const struct btf *btf, struct btf_field *field,
 	return 0;
 }
 
+static int btf_parse_list_head(const struct btf *btf, struct btf_field *field,
+			       struct btf_field_info *info)
+{
+	return btf_parse_graph_root(btf, field, info, "bpf_list_node",
+					    __alignof__(struct bpf_list_node));
+}
+
+static int btf_parse_rb_root(const struct btf *btf, struct btf_field *field,
+			     struct btf_field_info *info)
+{
+	return btf_parse_graph_root(btf, field, info, "bpf_rb_node",
+					    __alignof__(struct bpf_rb_node));
+}
+
 struct btf_record *btf_parse_fields(const struct btf *btf, const struct btf_type *t,
 				    u32 field_mask, u32 value_size)
 {
@@ -3699,7 +3727,13 @@ struct btf_record *btf_parse_fields(const struct btf *btf, const struct btf_type
 			if (ret < 0)
 				goto end;
 			break;
+		case BPF_RB_ROOT:
+			ret = btf_parse_rb_root(btf, &rec->fields[i], &info_arr[i]);
+			if (ret < 0)
+				goto end;
+			break;
 		case BPF_LIST_NODE:
+		case BPF_RB_NODE:
 			break;
 		default:
 			ret = -EFAULT;
@@ -3708,8 +3742,9 @@ struct btf_record *btf_parse_fields(const struct btf *btf, const struct btf_type
 		rec->cnt++;
 	}
 
-	/* bpf_list_head requires bpf_spin_lock */
-	if (btf_record_has_field(rec, BPF_LIST_HEAD) && rec->spin_lock_off < 0) {
+	/* bpf_{list_head, rb_node} require bpf_spin_lock */
+	if ((btf_record_has_field(rec, BPF_LIST_HEAD) ||
+	     btf_record_has_field(rec, BPF_RB_ROOT)) && rec->spin_lock_off < 0) {
 		ret = -EINVAL;
 		goto end;
 	}
@@ -3720,22 +3755,28 @@ struct btf_record *btf_parse_fields(const struct btf *btf, const struct btf_type
 	return ERR_PTR(ret);
 }
 
+#define GRAPH_ROOT_MASK (BPF_LIST_HEAD | BPF_RB_ROOT)
+#define GRAPH_NODE_MASK (BPF_LIST_NODE | BPF_RB_NODE)
+
 int btf_check_and_fixup_fields(const struct btf *btf, struct btf_record *rec)
 {
 	int i;
 
-	/* There are two owning types, kptr_ref and bpf_list_head. The former
-	 * only supports storing kernel types, which can never store references
-	 * to program allocated local types, atleast not yet. Hence we only need
-	 * to ensure that bpf_list_head ownership does not form cycles.
+	/* There are three types that signify ownership of some other type:
+	 *  kptr_ref, bpf_list_head, bpf_rb_root.
+	 * kptr_ref only supports storing kernel types, which can't store
+	 * references to program allocated local types.
+	 *
+	 * Hence we only need to ensure that bpf_{list_head,rb_root} ownership
+	 * does not form cycles.
 	 */
-	if (IS_ERR_OR_NULL(rec) || !(rec->field_mask & BPF_LIST_HEAD))
+	if (IS_ERR_OR_NULL(rec) || !(rec->field_mask & GRAPH_ROOT_MASK))
 		return 0;
 	for (i = 0; i < rec->cnt; i++) {
 		struct btf_struct_meta *meta;
 		u32 btf_id;
 
-		if (!(rec->fields[i].type & BPF_LIST_HEAD))
+		if (!(rec->fields[i].type & GRAPH_ROOT_MASK))
 			continue;
 		btf_id = rec->fields[i].graph_root.value_btf_id;
 		meta = btf_find_struct_meta(btf, btf_id);
@@ -3743,39 +3784,47 @@ int btf_check_and_fixup_fields(const struct btf *btf, struct btf_record *rec)
 			return -EFAULT;
 		rec->fields[i].graph_root.value_rec = meta->record;
 
-		if (!(rec->field_mask & BPF_LIST_NODE))
+		/* We need to set value_rec for all root types, but no need
+		 * to check ownership cycle for a type unless it's also a
+		 * node type.
+		 */
+		if (!(rec->field_mask & GRAPH_NODE_MASK))
 			continue;
 
 		/* We need to ensure ownership acyclicity among all types. The
 		 * proper way to do it would be to topologically sort all BTF
 		 * IDs based on the ownership edges, since there can be multiple
-		 * bpf_list_head in a type. Instead, we use the following
-		 * reasoning:
+		 * bpf_{list_head,rb_node} in a type. Instead, we use the
+		 * following resaoning:
 		 *
 		 * - A type can only be owned by another type in user BTF if it
-		 *   has a bpf_list_node.
+		 *   has a bpf_{list,rb}_node. Let's call these node types.
 		 * - A type can only _own_ another type in user BTF if it has a
-		 *   bpf_list_head.
+		 *   bpf_{list_head,rb_root}. Let's call these root types.
 		 *
-		 * We ensure that if a type has both bpf_list_head and
-		 * bpf_list_node, its element types cannot be owning types.
+		 * We ensure that if a type is both a root and node, its
+		 * element types cannot be root types.
 		 *
 		 * To ensure acyclicity:
 		 *
-		 * When A only has bpf_list_head, ownership chain can be:
+		 * When A is an root type but not a node, its ownership
+		 * chain can be:
 		 *	A -> B -> C
 		 * Where:
-		 * - B has both bpf_list_head and bpf_list_node.
-		 * - C only has bpf_list_node.
+		 * - A is an root, e.g. has bpf_rb_root.
+		 * - B is both a root and node, e.g. has bpf_rb_node and
+		 *   bpf_list_head.
+		 * - C is only an root, e.g. has bpf_list_node
 		 *
-		 * When A has both bpf_list_head and bpf_list_node, some other
-		 * type already owns it in the BTF domain, hence it can not own
-		 * another owning type through any of the bpf_list_head edges.
+		 * When A is both a root and node, some other type already
+		 * owns it in the BTF domain, hence it can not own
+		 * another root type through any of the ownership edges.
 		 *	A -> B
 		 * Where:
-		 * - B only has bpf_list_node.
+		 * - A is both an root and node.
+		 * - B is only an node.
 		 */
-		if (meta->record->field_mask & BPF_LIST_HEAD)
+		if (meta->record->field_mask & GRAPH_ROOT_MASK)
 			return -ELOOP;
 	}
 	return 0;
@@ -5237,6 +5286,8 @@ static const char *alloc_obj_fields[] = {
 	"bpf_spin_lock",
 	"bpf_list_head",
 	"bpf_list_node",
+	"bpf_rb_root",
+	"bpf_rb_node",
 };
 
 static struct btf_struct_metas *
@@ -5310,7 +5361,8 @@ btf_parse_struct_metas(struct bpf_verifier_log *log, struct btf *btf)
 
 		type = &tab->types[tab->cnt];
 		type->btf_id = i;
-		record = btf_parse_fields(btf, t, BPF_SPIN_LOCK | BPF_LIST_HEAD | BPF_LIST_NODE, t->size);
+		record = btf_parse_fields(btf, t, BPF_SPIN_LOCK | BPF_LIST_HEAD | BPF_LIST_NODE |
+						  BPF_RB_ROOT | BPF_RB_NODE, t->size);
 		/* The record cannot be unset, treat it as an error if so */
 		if (IS_ERR_OR_NULL(record)) {
 			ret = PTR_ERR_OR_ZERO(record) ?: -EFAULT;
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index 1df87af6919e..30fff015f9a1 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1761,6 +1761,46 @@ void bpf_list_head_free(const struct btf_field *field, void *list_head,
 	}
 }
 
+/* Like rbtree_postorder_for_each_entry_safe, but 'pos' and 'n' are
+ * 'rb_node *', so field name of rb_node within containing struct is not
+ * needed.
+ *
+ * Since bpf_rb_tree's node type has a corresponding struct btf_field with
+ * graph_root.node_offset, it's not necessary to know field name
+ * or type of node struct
+ */
+#define bpf_rbtree_postorder_for_each_entry_safe(pos, n, root) \
+	for (pos = rb_first_postorder(root); \
+	    pos && ({ n = rb_next_postorder(pos); 1; }); \
+	    pos = n)
+
+void bpf_rb_root_free(const struct btf_field *field, void *rb_root,
+		      struct bpf_spin_lock *spin_lock)
+{
+	struct rb_root_cached orig_root, *root = rb_root;
+	struct rb_node *pos, *n;
+	void *obj;
+
+	BUILD_BUG_ON(sizeof(struct rb_root_cached) > sizeof(struct bpf_rb_root));
+	BUILD_BUG_ON(__alignof__(struct rb_root_cached) > __alignof__(struct bpf_rb_root));
+
+	__bpf_spin_lock_irqsave(spin_lock);
+	orig_root = *root;
+	*root = RB_ROOT_CACHED;
+	__bpf_spin_unlock_irqrestore(spin_lock);
+
+	bpf_rbtree_postorder_for_each_entry_safe(pos, n, &orig_root.rb_root) {
+		obj = pos;
+		obj -= field->graph_root.node_offset;
+
+		bpf_obj_free_fields(field->graph_root.value_rec, obj);
+
+		migrate_disable();
+		bpf_mem_free(&bpf_global_ma, obj);
+		migrate_enable();
+	}
+}
+
 __diag_push();
 __diag_ignore_all("-Wmissing-prototypes",
 		  "Global functions as their definitions will be in vmlinux BTF");
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 35972afb6850..08e2def7ff93 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -527,9 +527,6 @@ void btf_record_free(struct btf_record *rec)
 		return;
 	for (i = 0; i < rec->cnt; i++) {
 		switch (rec->fields[i].type) {
-		case BPF_SPIN_LOCK:
-		case BPF_TIMER:
-			break;
 		case BPF_KPTR_UNREF:
 		case BPF_KPTR_REF:
 			if (rec->fields[i].kptr.module)
@@ -538,7 +535,11 @@ void btf_record_free(struct btf_record *rec)
 			break;
 		case BPF_LIST_HEAD:
 		case BPF_LIST_NODE:
-			/* Nothing to release for bpf_list_head */
+		case BPF_RB_ROOT:
+		case BPF_RB_NODE:
+		case BPF_SPIN_LOCK:
+		case BPF_TIMER:
+			/* Nothing to release */
 			break;
 		default:
 			WARN_ON_ONCE(1);
@@ -571,9 +572,6 @@ struct btf_record *btf_record_dup(const struct btf_record *rec)
 	new_rec->cnt = 0;
 	for (i = 0; i < rec->cnt; i++) {
 		switch (fields[i].type) {
-		case BPF_SPIN_LOCK:
-		case BPF_TIMER:
-			break;
 		case BPF_KPTR_UNREF:
 		case BPF_KPTR_REF:
 			btf_get(fields[i].kptr.btf);
@@ -584,7 +582,11 @@ struct btf_record *btf_record_dup(const struct btf_record *rec)
 			break;
 		case BPF_LIST_HEAD:
 		case BPF_LIST_NODE:
-			/* Nothing to acquire for bpf_list_head */
+		case BPF_RB_ROOT:
+		case BPF_RB_NODE:
+		case BPF_SPIN_LOCK:
+		case BPF_TIMER:
+			/* Nothing to acquire */
 			break;
 		default:
 			ret = -EFAULT;
@@ -664,7 +666,13 @@ void bpf_obj_free_fields(const struct btf_record *rec, void *obj)
 				continue;
 			bpf_list_head_free(field, field_ptr, obj + rec->spin_lock_off);
 			break;
+		case BPF_RB_ROOT:
+			if (WARN_ON_ONCE(rec->spin_lock_off < 0))
+				continue;
+			bpf_rb_root_free(field, field_ptr, obj + rec->spin_lock_off);
+			break;
 		case BPF_LIST_NODE:
+		case BPF_RB_NODE:
 			break;
 		default:
 			WARN_ON_ONCE(1);
@@ -1005,7 +1013,8 @@ static int map_check_btf(struct bpf_map *map, const struct btf *btf,
 		return -EINVAL;
 
 	map->record = btf_parse_fields(btf, value_type,
-				       BPF_SPIN_LOCK | BPF_TIMER | BPF_KPTR | BPF_LIST_HEAD,
+				       BPF_SPIN_LOCK | BPF_TIMER | BPF_KPTR | BPF_LIST_HEAD |
+				       BPF_RB_ROOT,
 				       map->value_size);
 	if (!IS_ERR_OR_NULL(map->record)) {
 		int i;
@@ -1053,6 +1062,7 @@ static int map_check_btf(struct bpf_map *map, const struct btf *btf,
 				}
 				break;
 			case BPF_LIST_HEAD:
+			case BPF_RB_ROOT:
 				if (map->map_type != BPF_MAP_TYPE_HASH &&
 				    map->map_type != BPF_MAP_TYPE_LRU_HASH &&
 				    map->map_type != BPF_MAP_TYPE_ARRAY) {
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index c914230beea7..89d8d754567b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -14392,9 +14392,10 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
 {
 	enum bpf_prog_type prog_type = resolve_prog_type(prog);
 
-	if (btf_record_has_field(map->record, BPF_LIST_HEAD)) {
+	if (btf_record_has_field(map->record, BPF_LIST_HEAD) ||
+	    btf_record_has_field(map->record, BPF_RB_ROOT)) {
 		if (is_tracing_prog_type(prog_type)) {
-			verbose(env, "tracing progs cannot use bpf_list_head yet\n");
+			verbose(env, "tracing progs cannot use bpf_{list_head,rb_root} yet\n");
 			return -EINVAL;
 		}
 	}
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 464ca3f01fe7..bd260134c420 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -6901,6 +6901,17 @@ struct bpf_list_node {
 	__u64 :64;
 } __attribute__((aligned(8)));
 
+struct bpf_rb_root {
+	__u64 :64;
+	__u64 :64;
+} __attribute__((aligned(8)));
+
+struct bpf_rb_node {
+	__u64 :64;
+	__u64 :64;
+	__u64 :64;
+} __attribute__((aligned(8)));
+
 struct bpf_sysctl {
 	__u32	write;		/* Sysctl is being read (= 0) or written (= 1).
 				 * Allows 1,2,4-byte read, but no write.
diff --git a/tools/testing/selftests/bpf/prog_tests/linked_list.c b/tools/testing/selftests/bpf/prog_tests/linked_list.c
index a8091a0c0831..d44ba935207f 100644
--- a/tools/testing/selftests/bpf/prog_tests/linked_list.c
+++ b/tools/testing/selftests/bpf/prog_tests/linked_list.c
@@ -58,12 +58,12 @@ static struct {
 	TEST(inner_map, pop_front)
 	TEST(inner_map, pop_back)
 #undef TEST
-	{ "map_compat_kprobe", "tracing progs cannot use bpf_list_head yet" },
-	{ "map_compat_kretprobe", "tracing progs cannot use bpf_list_head yet" },
-	{ "map_compat_tp", "tracing progs cannot use bpf_list_head yet" },
-	{ "map_compat_perf", "tracing progs cannot use bpf_list_head yet" },
-	{ "map_compat_raw_tp", "tracing progs cannot use bpf_list_head yet" },
-	{ "map_compat_raw_tp_w", "tracing progs cannot use bpf_list_head yet" },
+	{ "map_compat_kprobe", "tracing progs cannot use bpf_{list_head,rb_root} yet" },
+	{ "map_compat_kretprobe", "tracing progs cannot use bpf_{list_head,rb_root} yet" },
+	{ "map_compat_tp", "tracing progs cannot use bpf_{list_head,rb_root} yet" },
+	{ "map_compat_perf", "tracing progs cannot use bpf_{list_head,rb_root} yet" },
+	{ "map_compat_raw_tp", "tracing progs cannot use bpf_{list_head,rb_root} yet" },
+	{ "map_compat_raw_tp_w", "tracing progs cannot use bpf_{list_head,rb_root} yet" },
 	{ "obj_type_id_oor", "local type ID argument must be in range [0, U32_MAX]" },
 	{ "obj_new_no_composite", "bpf_obj_new type ID argument must be of a struct" },
 	{ "obj_new_no_struct", "bpf_obj_new type ID argument must be of a struct" },
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 06/13] bpf: Add bpf_rbtree_{add,remove,first} kfuncs
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (4 preceding siblings ...)
  2022-12-17  8:24 ` [PATCH v2 bpf-next 05/13] bpf: Add basic bpf_rb_{root,node} support Dave Marchevsky
@ 2022-12-17  8:24 ` Dave Marchevsky
  2022-12-17  8:25 ` [PATCH v2 bpf-next 07/13] bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args Dave Marchevsky
                   ` (6 subsequent siblings)
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:24 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

This patch adds implementations of bpf_rbtree_{add,remove,first}
and teaches verifier about their BTF_IDs as well as those of
bpf_rb_{root,node}.

All three kfuncs have some nonstandard component to their verification
that needs to be addressed in future patches before programs can
properly use them:

  * bpf_rbtree_add:     Takes 'less' callback, need to verify it

  * bpf_rbtree_first:   Returns ptr_to_node_type(off=rb_node_off) instead
                        of ptr_to_rb_node(off=0). Return value ref is
			non-owning.

  * bpf_rbtree_remove:  Returns ptr_to_node_type(off=rb_node_off) instead
                        of ptr_to_rb_node(off=0). 2nd arg (node) is a
			non-owning reference.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 kernel/bpf/helpers.c  | 28 ++++++++++++++++++++++++++++
 kernel/bpf/verifier.c | 11 +++++++++++
 2 files changed, 39 insertions(+)

diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index 30fff015f9a1..de4523c777b7 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1873,6 +1873,30 @@ struct bpf_list_node *bpf_list_pop_back(struct bpf_list_head *head)
 	return __bpf_list_del(head, true);
 }
 
+struct bpf_rb_node *bpf_rbtree_remove(struct bpf_rb_root *root, struct bpf_rb_node *node)
+{
+	struct rb_root_cached *r = (struct rb_root_cached *)root;
+	struct rb_node *n = (struct rb_node *)node;
+
+	rb_erase_cached(n, r);
+	RB_CLEAR_NODE(n);
+	return (struct bpf_rb_node *)n;
+}
+
+void bpf_rbtree_add(struct bpf_rb_root *root, struct bpf_rb_node *node,
+		    bool (less)(struct bpf_rb_node *a, const struct bpf_rb_node *b))
+{
+	rb_add_cached((struct rb_node *)node, (struct rb_root_cached *)root,
+		      (bool (*)(struct rb_node *, const struct rb_node *))less);
+}
+
+struct bpf_rb_node *bpf_rbtree_first(struct bpf_rb_root *root)
+{
+	struct rb_root_cached *r = (struct rb_root_cached *)root;
+
+	return (struct bpf_rb_node *)rb_first_cached(r);
+}
+
 /**
  * bpf_task_acquire - Acquire a reference to a task. A task acquired by this
  * kfunc which is not stored in a map as a kptr, must be released by calling
@@ -2097,6 +2121,10 @@ BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
 BTF_ID_FLAGS(func, bpf_task_acquire_not_zero, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_task_kptr_get, KF_ACQUIRE | KF_KPTR_GET | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_task_release, KF_RELEASE)
+BTF_ID_FLAGS(func, bpf_rbtree_remove, KF_ACQUIRE)
+BTF_ID_FLAGS(func, bpf_rbtree_add, KF_RELEASE | KF_RELEASE_NON_OWN)
+BTF_ID_FLAGS(func, bpf_rbtree_first, KF_RET_NULL)
+
 #ifdef CONFIG_CGROUPS
 BTF_ID_FLAGS(func, bpf_cgroup_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
 BTF_ID_FLAGS(func, bpf_cgroup_kptr_get, KF_ACQUIRE | KF_KPTR_GET | KF_RET_NULL)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 89d8d754567b..e90cf0b74571 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -8406,6 +8406,8 @@ BTF_ID_LIST(kf_arg_btf_ids)
 BTF_ID(struct, bpf_dynptr_kern)
 BTF_ID(struct, bpf_list_head)
 BTF_ID(struct, bpf_list_node)
+BTF_ID(struct, bpf_rb_root)
+BTF_ID(struct, bpf_rb_node)
 
 static bool __is_kfunc_ptr_arg_type(const struct btf *btf,
 				    const struct btf_param *arg, int type)
@@ -8511,6 +8513,9 @@ enum special_kfunc_type {
 	KF_bpf_rdonly_cast,
 	KF_bpf_rcu_read_lock,
 	KF_bpf_rcu_read_unlock,
+	KF_bpf_rbtree_remove,
+	KF_bpf_rbtree_add,
+	KF_bpf_rbtree_first,
 };
 
 BTF_SET_START(special_kfunc_set)
@@ -8522,6 +8527,9 @@ BTF_ID(func, bpf_list_pop_front)
 BTF_ID(func, bpf_list_pop_back)
 BTF_ID(func, bpf_cast_to_kern_ctx)
 BTF_ID(func, bpf_rdonly_cast)
+BTF_ID(func, bpf_rbtree_remove)
+BTF_ID(func, bpf_rbtree_add)
+BTF_ID(func, bpf_rbtree_first)
 BTF_SET_END(special_kfunc_set)
 
 BTF_ID_LIST(special_kfunc_list)
@@ -8535,6 +8543,9 @@ BTF_ID(func, bpf_cast_to_kern_ctx)
 BTF_ID(func, bpf_rdonly_cast)
 BTF_ID(func, bpf_rcu_read_lock)
 BTF_ID(func, bpf_rcu_read_unlock)
+BTF_ID(func, bpf_rbtree_remove)
+BTF_ID(func, bpf_rbtree_add)
+BTF_ID(func, bpf_rbtree_first)
 
 static bool is_kfunc_bpf_rcu_read_lock(struct bpf_kfunc_call_arg_meta *meta)
 {
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 07/13] bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (5 preceding siblings ...)
  2022-12-17  8:24 ` [PATCH v2 bpf-next 06/13] bpf: Add bpf_rbtree_{add,remove,first} kfuncs Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-29  4:00   ` Alexei Starovoitov
  2022-12-17  8:25 ` [PATCH v2 bpf-next 08/13] bpf: Add callback validation to kfunc verifier logic Dave Marchevsky
                   ` (5 subsequent siblings)
  12 siblings, 1 reply; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

Now that we find bpf_rb_root and bpf_rb_node in structs, let's give args
that contain those types special classification and properly handle
these types when checking kfunc args.

"Properly handling" these types largely requires generalizing similar
handling for bpf_list_{head,node}, with little new logic added in this
patch.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 kernel/bpf/verifier.c | 238 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 203 insertions(+), 35 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index e90cf0b74571..06ab0eb6ee7f 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -8284,6 +8284,9 @@ struct bpf_kfunc_call_arg_meta {
 	struct {
 		struct btf_field *field;
 	} arg_list_head;
+	struct {
+		struct btf_field *field;
+	} arg_rbtree_root;
 };
 
 static bool is_kfunc_acquire(struct bpf_kfunc_call_arg_meta *meta)
@@ -8400,6 +8403,8 @@ enum {
 	KF_ARG_DYNPTR_ID,
 	KF_ARG_LIST_HEAD_ID,
 	KF_ARG_LIST_NODE_ID,
+	KF_ARG_RB_ROOT_ID,
+	KF_ARG_RB_NODE_ID,
 };
 
 BTF_ID_LIST(kf_arg_btf_ids)
@@ -8441,6 +8446,16 @@ static bool is_kfunc_arg_list_node(const struct btf *btf, const struct btf_param
 	return __is_kfunc_ptr_arg_type(btf, arg, KF_ARG_LIST_NODE_ID);
 }
 
+static bool is_kfunc_arg_rbtree_root(const struct btf *btf, const struct btf_param *arg)
+{
+	return __is_kfunc_ptr_arg_type(btf, arg, KF_ARG_RB_ROOT_ID);
+}
+
+static bool is_kfunc_arg_rbtree_node(const struct btf *btf, const struct btf_param *arg)
+{
+	return __is_kfunc_ptr_arg_type(btf, arg, KF_ARG_RB_NODE_ID);
+}
+
 /* Returns true if struct is composed of scalars, 4 levels of nesting allowed */
 static bool __btf_type_is_scalar_struct(struct bpf_verifier_env *env,
 					const struct btf *btf,
@@ -8500,6 +8515,8 @@ enum kfunc_ptr_arg_type {
 	KF_ARG_PTR_TO_BTF_ID,	     /* Also covers reg2btf_ids conversions */
 	KF_ARG_PTR_TO_MEM,
 	KF_ARG_PTR_TO_MEM_SIZE,	     /* Size derived from next argument, skip it */
+	KF_ARG_PTR_TO_RB_ROOT,
+	KF_ARG_PTR_TO_RB_NODE,
 };
 
 enum special_kfunc_type {
@@ -8607,6 +8624,12 @@ get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
 	if (is_kfunc_arg_list_node(meta->btf, &args[argno]))
 		return KF_ARG_PTR_TO_LIST_NODE;
 
+	if (is_kfunc_arg_rbtree_root(meta->btf, &args[argno]))
+		return KF_ARG_PTR_TO_RB_ROOT;
+
+	if (is_kfunc_arg_rbtree_node(meta->btf, &args[argno]))
+		return KF_ARG_PTR_TO_RB_NODE;
+
 	if ((base_type(reg->type) == PTR_TO_BTF_ID || reg2btf_ids[base_type(reg->type)])) {
 		if (!btf_type_is_struct(ref_t)) {
 			verbose(env, "kernel function %s args#%d pointer type %s %s is not supported\n",
@@ -8836,95 +8859,193 @@ static bool is_bpf_list_api_kfunc(u32 btf_id)
 	       btf_id == special_kfunc_list[KF_bpf_list_pop_back];
 }
 
-static int process_kf_arg_ptr_to_list_head(struct bpf_verifier_env *env,
-					   struct bpf_reg_state *reg, u32 regno,
-					   struct bpf_kfunc_call_arg_meta *meta)
+static bool is_bpf_rbtree_api_kfunc(u32 btf_id)
+{
+	return btf_id == special_kfunc_list[KF_bpf_rbtree_add] ||
+	       btf_id == special_kfunc_list[KF_bpf_rbtree_remove] ||
+	       btf_id == special_kfunc_list[KF_bpf_rbtree_first];
+}
+
+static bool is_bpf_graph_api_kfunc(u32 btf_id)
+{
+	return is_bpf_list_api_kfunc(btf_id) || is_bpf_rbtree_api_kfunc(btf_id);
+}
+
+static bool check_kfunc_is_graph_root_api(struct bpf_verifier_env *env,
+					  enum btf_field_type head_field_type,
+					  u32 kfunc_btf_id)
 {
+	bool ret;
+
+	switch (head_field_type) {
+	case BPF_LIST_HEAD:
+		ret = is_bpf_list_api_kfunc(kfunc_btf_id);
+		break;
+	case BPF_RB_ROOT:
+		ret = is_bpf_rbtree_api_kfunc(kfunc_btf_id);
+		break;
+	default:
+		verbose(env, "verifier internal error: unexpected graph root argument type %s\n",
+			btf_field_type_name(head_field_type));
+		return false;
+	}
+
+	if (!ret)
+		verbose(env, "verifier internal error: %s head arg for unknown kfunc\n",
+			btf_field_type_name(head_field_type));
+	return ret;
+}
+
+static bool check_kfunc_is_graph_node_api(struct bpf_verifier_env *env,
+					  enum btf_field_type node_field_type,
+					  u32 kfunc_btf_id)
+{
+	bool ret;
+
+	switch (node_field_type) {
+	case BPF_LIST_NODE:
+		ret = (kfunc_btf_id == special_kfunc_list[KF_bpf_list_push_front] ||
+		       kfunc_btf_id == special_kfunc_list[KF_bpf_list_push_back]);
+		break;
+	case BPF_RB_NODE:
+		ret = (kfunc_btf_id == special_kfunc_list[KF_bpf_rbtree_remove] ||
+		       kfunc_btf_id == special_kfunc_list[KF_bpf_rbtree_add]);
+		break;
+	default:
+		verbose(env, "verifier internal error: unexpected graph node argument type %s\n",
+			btf_field_type_name(node_field_type));
+		return false;
+	}
+
+	if (!ret)
+		verbose(env, "verifier internal error: %s node arg for unknown kfunc\n",
+			btf_field_type_name(node_field_type));
+	return ret;
+}
+
+static int
+__process_kf_arg_ptr_to_graph_root(struct bpf_verifier_env *env,
+				   struct bpf_reg_state *reg, u32 regno,
+				   struct bpf_kfunc_call_arg_meta *meta,
+				   enum btf_field_type head_field_type,
+				   struct btf_field **head_field)
+{
+	const char *head_type_name;
 	struct btf_field *field;
 	struct btf_record *rec;
-	u32 list_head_off;
+	u32 head_off;
 
-	if (meta->btf != btf_vmlinux || !is_bpf_list_api_kfunc(meta->func_id)) {
-		verbose(env, "verifier internal error: bpf_list_head argument for unknown kfunc\n");
+	if (meta->btf != btf_vmlinux) {
+		verbose(env, "verifier internal error: unexpected btf mismatch in kfunc call\n");
 		return -EFAULT;
 	}
 
+	if (!check_kfunc_is_graph_root_api(env, head_field_type, meta->func_id))
+		return -EFAULT;
+
+	head_type_name = btf_field_type_name(head_field_type);
 	if (!tnum_is_const(reg->var_off)) {
 		verbose(env,
-			"R%d doesn't have constant offset. bpf_list_head has to be at the constant offset\n",
-			regno);
+			"R%d doesn't have constant offset. %s has to be at the constant offset\n",
+			regno, head_type_name);
 		return -EINVAL;
 	}
 
 	rec = reg_btf_record(reg);
-	list_head_off = reg->off + reg->var_off.value;
-	field = btf_record_find(rec, list_head_off, BPF_LIST_HEAD);
+	head_off = reg->off + reg->var_off.value;
+	field = btf_record_find(rec, head_off, head_field_type);
 	if (!field) {
-		verbose(env, "bpf_list_head not found at offset=%u\n", list_head_off);
+		verbose(env, "%s not found at offset=%u\n", head_type_name, head_off);
 		return -EINVAL;
 	}
 
 	/* All functions require bpf_list_head to be protected using a bpf_spin_lock */
 	if (check_reg_allocation_locked(env, reg)) {
-		verbose(env, "bpf_spin_lock at off=%d must be held for bpf_list_head\n",
-			rec->spin_lock_off);
+		verbose(env, "bpf_spin_lock at off=%d must be held for %s\n",
+			rec->spin_lock_off, head_type_name);
 		return -EINVAL;
 	}
 
-	if (meta->arg_list_head.field) {
-		verbose(env, "verifier internal error: repeating bpf_list_head arg\n");
+	if (*head_field) {
+		verbose(env, "verifier internal error: repeating %s arg\n", head_type_name);
 		return -EFAULT;
 	}
-	meta->arg_list_head.field = field;
+	*head_field = field;
 	return 0;
 }
 
-static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
+static int process_kf_arg_ptr_to_list_head(struct bpf_verifier_env *env,
 					   struct bpf_reg_state *reg, u32 regno,
 					   struct bpf_kfunc_call_arg_meta *meta)
 {
+	return __process_kf_arg_ptr_to_graph_root(env, reg, regno, meta, BPF_LIST_HEAD,
+							  &meta->arg_list_head.field);
+}
+
+static int process_kf_arg_ptr_to_rbtree_root(struct bpf_verifier_env *env,
+					     struct bpf_reg_state *reg, u32 regno,
+					     struct bpf_kfunc_call_arg_meta *meta)
+{
+	return __process_kf_arg_ptr_to_graph_root(env, reg, regno, meta, BPF_RB_ROOT,
+							  &meta->arg_rbtree_root.field);
+}
+
+static int
+__process_kf_arg_ptr_to_graph_node(struct bpf_verifier_env *env,
+				   struct bpf_reg_state *reg, u32 regno,
+				   struct bpf_kfunc_call_arg_meta *meta,
+				   enum btf_field_type head_field_type,
+				   enum btf_field_type node_field_type,
+				   struct btf_field **node_field)
+{
+	const char *node_type_name;
 	const struct btf_type *et, *t;
 	struct btf_field *field;
-	u32 list_node_off;
+	u32 node_off;
 
-	if (meta->btf != btf_vmlinux ||
-	    (meta->func_id != special_kfunc_list[KF_bpf_list_push_front] &&
-	     meta->func_id != special_kfunc_list[KF_bpf_list_push_back])) {
-		verbose(env, "verifier internal error: bpf_list_node argument for unknown kfunc\n");
+	if (meta->btf != btf_vmlinux) {
+		verbose(env, "verifier internal error: unexpected btf mismatch in kfunc call\n");
 		return -EFAULT;
 	}
 
+	if (!check_kfunc_is_graph_node_api(env, node_field_type, meta->func_id))
+		return -EFAULT;
+
+	node_type_name = btf_field_type_name(node_field_type);
 	if (!tnum_is_const(reg->var_off)) {
 		verbose(env,
-			"R%d doesn't have constant offset. bpf_list_node has to be at the constant offset\n",
-			regno);
+			"R%d doesn't have constant offset. %s has to be at the constant offset\n",
+			regno, node_type_name);
 		return -EINVAL;
 	}
 
-	list_node_off = reg->off + reg->var_off.value;
-	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
-	if (!field || field->offset != list_node_off) {
-		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
+	node_off = reg->off + reg->var_off.value;
+	field = reg_find_field_offset(reg, node_off, node_field_type);
+	if (!field || field->offset != node_off) {
+		verbose(env, "%s not found at offset=%u\n", node_type_name, node_off);
 		return -EINVAL;
 	}
 
-	field = meta->arg_list_head.field;
+	field = *node_field;
 
 	et = btf_type_by_id(field->graph_root.btf, field->graph_root.value_btf_id);
 	t = btf_type_by_id(reg->btf, reg->btf_id);
 	if (!btf_struct_ids_match(&env->log, reg->btf, reg->btf_id, 0, field->graph_root.btf,
 				  field->graph_root.value_btf_id, true)) {
-		verbose(env, "operation on bpf_list_head expects arg#1 bpf_list_node at offset=%d "
+		verbose(env, "operation on %s expects arg#1 %s at offset=%d "
 			"in struct %s, but arg is at offset=%d in struct %s\n",
+			btf_field_type_name(head_field_type),
+			btf_field_type_name(node_field_type),
 			field->graph_root.node_offset,
 			btf_name_by_offset(field->graph_root.btf, et->name_off),
-			list_node_off, btf_name_by_offset(reg->btf, t->name_off));
+			node_off, btf_name_by_offset(reg->btf, t->name_off));
 		return -EINVAL;
 	}
 
-	if (list_node_off != field->graph_root.node_offset) {
-		verbose(env, "arg#1 offset=%d, but expected bpf_list_node at offset=%d in struct %s\n",
-			list_node_off, field->graph_root.node_offset,
+	if (node_off != field->graph_root.node_offset) {
+		verbose(env, "arg#1 offset=%d, but expected %s at offset=%d in struct %s\n",
+			node_off, btf_field_type_name(node_field_type),
+			field->graph_root.node_offset,
 			btf_name_by_offset(field->graph_root.btf, et->name_off));
 		return -EINVAL;
 	}
@@ -8932,6 +9053,24 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
 	return 0;
 }
 
+static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
+					   struct bpf_reg_state *reg, u32 regno,
+					   struct bpf_kfunc_call_arg_meta *meta)
+{
+	return __process_kf_arg_ptr_to_graph_node(env, reg, regno, meta,
+						  BPF_LIST_HEAD, BPF_LIST_NODE,
+						  &meta->arg_list_head.field);
+}
+
+static int process_kf_arg_ptr_to_rbtree_node(struct bpf_verifier_env *env,
+					     struct bpf_reg_state *reg, u32 regno,
+					     struct bpf_kfunc_call_arg_meta *meta)
+{
+	return __process_kf_arg_ptr_to_graph_node(env, reg, regno, meta,
+						  BPF_RB_ROOT, BPF_RB_NODE,
+						  &meta->arg_rbtree_root.field);
+}
+
 static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
 {
 	const char *func_name = meta->func_name, *ref_tname;
@@ -9063,6 +9202,8 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 		case KF_ARG_PTR_TO_DYNPTR:
 		case KF_ARG_PTR_TO_LIST_HEAD:
 		case KF_ARG_PTR_TO_LIST_NODE:
+		case KF_ARG_PTR_TO_RB_ROOT:
+		case KF_ARG_PTR_TO_RB_NODE:
 		case KF_ARG_PTR_TO_MEM:
 		case KF_ARG_PTR_TO_MEM_SIZE:
 			/* Trusted by default */
@@ -9141,6 +9282,20 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 			if (ret < 0)
 				return ret;
 			break;
+		case KF_ARG_PTR_TO_RB_ROOT:
+			if (reg->type != PTR_TO_MAP_VALUE &&
+			    reg->type != (PTR_TO_BTF_ID | MEM_ALLOC)) {
+				verbose(env, "arg#%d expected pointer to map value or allocated object\n", i);
+				return -EINVAL;
+			}
+			if (reg->type == (PTR_TO_BTF_ID | MEM_ALLOC) && !reg->ref_obj_id) {
+				verbose(env, "allocated object must be referenced\n");
+				return -EINVAL;
+			}
+			ret = process_kf_arg_ptr_to_rbtree_root(env, reg, regno, meta);
+			if (ret < 0)
+				return ret;
+			break;
 		case KF_ARG_PTR_TO_LIST_NODE:
 			if (reg->type != (PTR_TO_BTF_ID | MEM_ALLOC)) {
 				verbose(env, "arg#%d expected pointer to allocated object\n", i);
@@ -9154,6 +9309,19 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 			if (ret < 0)
 				return ret;
 			break;
+		case KF_ARG_PTR_TO_RB_NODE:
+			if (reg->type != (PTR_TO_BTF_ID | MEM_ALLOC)) {
+				verbose(env, "arg#%d expected pointer to allocated object\n", i);
+				return -EINVAL;
+			}
+			if (!reg->ref_obj_id) {
+				verbose(env, "allocated object must be referenced\n");
+				return -EINVAL;
+			}
+			ret = process_kf_arg_ptr_to_rbtree_node(env, reg, regno, meta);
+			if (ret < 0)
+				return ret;
+			break;
 		case KF_ARG_PTR_TO_BTF_ID:
 			/* Only base_type is checked, further checks are done here */
 			if ((base_type(reg->type) != PTR_TO_BTF_ID ||
@@ -14105,7 +14273,7 @@ static int do_check(struct bpf_verifier_env *env)
 					if ((insn->src_reg == BPF_REG_0 && insn->imm != BPF_FUNC_spin_unlock) ||
 					    (insn->src_reg == BPF_PSEUDO_CALL) ||
 					    (insn->src_reg == BPF_PSEUDO_KFUNC_CALL &&
-					     (insn->off != 0 || !is_bpf_list_api_kfunc(insn->imm)))) {
+					     (insn->off != 0 || !is_bpf_graph_api_kfunc(insn->imm)))) {
 						verbose(env, "function calls are not allowed while holding a lock\n");
 						return -EINVAL;
 					}
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 08/13] bpf: Add callback validation to kfunc verifier logic
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (6 preceding siblings ...)
  2022-12-17  8:25 ` [PATCH v2 bpf-next 07/13] bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-17  8:25 ` [PATCH v2 bpf-next 09/13] bpf: Special verifier handling for bpf_rbtree_{remove, first} Dave Marchevsky
                   ` (4 subsequent siblings)
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

Some BPF helpers take a callback function which the helper calls. For
each helper that takes such a callback, there's a special call to
__check_func_call with a callback-state-setting callback that sets up
verifier bpf_func_state for the callback's frame.

kfuncs don't have any of this infrastructure yet, so let's add it in
this patch, following existing helper pattern as much as possible. To
validate functionality of this added plumbing, this patch adds
callback handling for the bpf_rbtree_add kfunc and hopes to lay
groundwork for future graph datastructure callbacks.

In the "general plumbing" category we have:

  * check_kfunc_call doing callback verification right before clearing
    CALLER_SAVED_REGS, exactly like check_helper_call
  * recognition of func_ptr BTF types in kfunc args as
    KF_ARG_PTR_TO_CALLBACK + propagation of subprogno for this arg type

In the "rbtree_add / graph datastructure-specific plumbing" category:

  * Since bpf_rbtree_add must be called while the spin_lock associated
    with the tree is held, don't complain when callback's func_state
    doesn't unlock it by frame exit
  * Mark rbtree_add callback's args with ref_set_non_owning_lock
    to prevent rbtree api functions from being called in the callback.
    Semantically this makes sense, as less() takes no ownership of its
    args when determining which comes first.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 kernel/bpf/verifier.c | 135 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 130 insertions(+), 5 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 06ab0eb6ee7f..75979f78399d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -192,6 +192,8 @@ static int acquire_reference_state(struct bpf_verifier_env *env, int insn_idx);
 static int release_reference(struct bpf_verifier_env *env, int ref_obj_id);
 static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
 				       struct bpf_active_lock *lock);
+static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env);
+
 static int ref_set_non_owning_lock(struct bpf_verifier_env *env,
 				   struct bpf_reg_state *reg);
 
@@ -1491,6 +1493,16 @@ static void mark_ptr_not_null_reg(struct bpf_reg_state *reg)
 	reg->type &= ~PTR_MAYBE_NULL;
 }
 
+static void mark_reg_graph_node(struct bpf_reg_state *regs, u32 regno,
+				struct btf_field_graph_root *ds_head)
+{
+	__mark_reg_known_zero(&regs[regno]);
+	regs[regno].type = PTR_TO_BTF_ID | MEM_ALLOC;
+	regs[regno].btf = ds_head->btf;
+	regs[regno].btf_id = ds_head->value_btf_id;
+	regs[regno].off = ds_head->node_offset;
+}
+
 static bool reg_is_pkt_pointer(const struct bpf_reg_state *reg)
 {
 	return type_is_pkt_pointer(reg->type);
@@ -6504,6 +6516,10 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
 		meta->ret_btf_id = reg->btf_id;
 		break;
 	case ARG_PTR_TO_SPIN_LOCK:
+		if (in_rbtree_lock_required_cb(env)) {
+			verbose(env, "can't spin_{lock,unlock} in rbtree cb\n");
+			return -EACCES;
+		}
 		if (meta->func_id == BPF_FUNC_spin_lock) {
 			err = process_spin_lock(env, regno, true);
 			if (err)
@@ -7111,6 +7127,8 @@ static int set_callee_state(struct bpf_verifier_env *env,
 			    struct bpf_func_state *caller,
 			    struct bpf_func_state *callee, int insn_idx);
 
+static bool is_callback_calling_kfunc(u32 btf_id);
+
 static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 			     int *insn_idx, int subprog,
 			     set_callee_state_fn set_callee_state_cb)
@@ -7165,10 +7183,18 @@ static int __check_func_call(struct bpf_verifier_env *env, struct bpf_insn *insn
 	 * interested in validating only BPF helpers that can call subprogs as
 	 * callbacks
 	 */
-	if (set_callee_state_cb != set_callee_state && !is_callback_calling_function(insn->imm)) {
-		verbose(env, "verifier bug: helper %s#%d is not marked as callback-calling\n",
-			func_id_name(insn->imm), insn->imm);
-		return -EFAULT;
+	if (set_callee_state_cb != set_callee_state) {
+		if (bpf_pseudo_kfunc_call(insn) &&
+		    !is_callback_calling_kfunc(insn->imm)) {
+			verbose(env, "verifier bug: kfunc %s#%d not marked as callback-calling\n",
+				func_id_name(insn->imm), insn->imm);
+			return -EFAULT;
+		} else if (!bpf_pseudo_kfunc_call(insn) &&
+			   !is_callback_calling_function(insn->imm)) { /* helper */
+			verbose(env, "verifier bug: helper %s#%d not marked as callback-calling\n",
+				func_id_name(insn->imm), insn->imm);
+			return -EFAULT;
+		}
 	}
 
 	if (insn->code == (BPF_JMP | BPF_CALL) &&
@@ -7433,6 +7459,63 @@ static int set_user_ringbuf_callback_state(struct bpf_verifier_env *env,
 	return 0;
 }
 
+static int set_rbtree_add_callback_state(struct bpf_verifier_env *env,
+					 struct bpf_func_state *caller,
+					 struct bpf_func_state *callee,
+					 int insn_idx)
+{
+	/* void bpf_rbtree_add(struct bpf_rb_root *root, struct bpf_rb_node *node,
+	 *                     bool (less)(struct bpf_rb_node *a, const struct bpf_rb_node *b));
+	 *
+	 * 'struct bpf_rb_node *node' arg to bpf_rbtree_add is the same PTR_TO_BTF_ID w/ offset
+	 * that 'less' callback args will be receiving. However, 'node' arg was release_reference'd
+	 * by this point, so look at 'root'
+	 */
+	struct btf_field *field;
+
+	field = reg_find_field_offset(&caller->regs[BPF_REG_1], caller->regs[BPF_REG_1].off,
+				      BPF_RB_ROOT);
+	if (!field || !field->graph_root.value_btf_id)
+		return -EFAULT;
+
+	mark_reg_graph_node(callee->regs, BPF_REG_1, &field->graph_root);
+	ref_set_non_owning_lock(env, &callee->regs[BPF_REG_1]);
+	mark_reg_graph_node(callee->regs, BPF_REG_2, &field->graph_root);
+	ref_set_non_owning_lock(env, &callee->regs[BPF_REG_2]);
+
+	__mark_reg_not_init(env, &callee->regs[BPF_REG_3]);
+	__mark_reg_not_init(env, &callee->regs[BPF_REG_4]);
+	__mark_reg_not_init(env, &callee->regs[BPF_REG_5]);
+	callee->in_callback_fn = true;
+	callee->callback_ret_range = tnum_range(0, 1);
+	return 0;
+}
+
+static bool is_rbtree_lock_required_kfunc(u32 btf_id);
+
+/* Are we currently verifying the callback for a rbtree helper that must
+ * be called with lock held? If so, no need to complain about unreleased
+ * lock
+ */
+static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env)
+{
+	struct bpf_verifier_state *state = env->cur_state;
+	struct bpf_insn *insn = env->prog->insnsi;
+	struct bpf_func_state *callee;
+	int kfunc_btf_id;
+
+	if (!state->curframe)
+		return false;
+
+	callee = state->frame[state->curframe];
+
+	if (!callee->in_callback_fn)
+		return false;
+
+	kfunc_btf_id = insn[callee->callsite].imm;
+	return is_rbtree_lock_required_kfunc(kfunc_btf_id);
+}
+
 static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
 {
 	struct bpf_verifier_state *state = env->cur_state;
@@ -8273,6 +8356,7 @@ struct bpf_kfunc_call_arg_meta {
 	bool r0_rdonly;
 	u32 ret_btf_id;
 	u64 r0_size;
+	u32 subprogno;
 	struct {
 		u64 value;
 		bool found;
@@ -8456,6 +8540,18 @@ static bool is_kfunc_arg_rbtree_node(const struct btf *btf, const struct btf_par
 	return __is_kfunc_ptr_arg_type(btf, arg, KF_ARG_RB_NODE_ID);
 }
 
+static bool is_kfunc_arg_callback(struct bpf_verifier_env *env, const struct btf *btf,
+				  const struct btf_param *arg)
+{
+	const struct btf_type *t;
+
+	t = btf_type_resolve_func_ptr(btf, arg->type, NULL);
+	if (!t)
+		return false;
+
+	return true;
+}
+
 /* Returns true if struct is composed of scalars, 4 levels of nesting allowed */
 static bool __btf_type_is_scalar_struct(struct bpf_verifier_env *env,
 					const struct btf *btf,
@@ -8515,6 +8611,7 @@ enum kfunc_ptr_arg_type {
 	KF_ARG_PTR_TO_BTF_ID,	     /* Also covers reg2btf_ids conversions */
 	KF_ARG_PTR_TO_MEM,
 	KF_ARG_PTR_TO_MEM_SIZE,	     /* Size derived from next argument, skip it */
+	KF_ARG_PTR_TO_CALLBACK,
 	KF_ARG_PTR_TO_RB_ROOT,
 	KF_ARG_PTR_TO_RB_NODE,
 };
@@ -8639,6 +8736,9 @@ get_kfunc_ptr_arg_type(struct bpf_verifier_env *env,
 		return KF_ARG_PTR_TO_BTF_ID;
 	}
 
+	if (is_kfunc_arg_callback(env, meta->btf, &args[argno]))
+		return KF_ARG_PTR_TO_CALLBACK;
+
 	if (argno + 1 < nargs && is_kfunc_arg_mem_size(meta->btf, &args[argno + 1], &regs[regno + 1]))
 		arg_mem_size = true;
 
@@ -8871,6 +8971,16 @@ static bool is_bpf_graph_api_kfunc(u32 btf_id)
 	return is_bpf_list_api_kfunc(btf_id) || is_bpf_rbtree_api_kfunc(btf_id);
 }
 
+static bool is_callback_calling_kfunc(u32 btf_id)
+{
+	return btf_id == special_kfunc_list[KF_bpf_rbtree_add];
+}
+
+static bool is_rbtree_lock_required_kfunc(u32 btf_id)
+{
+	return is_bpf_rbtree_api_kfunc(btf_id);
+}
+
 static bool check_kfunc_is_graph_root_api(struct bpf_verifier_env *env,
 					  enum btf_field_type head_field_type,
 					  u32 kfunc_btf_id)
@@ -9206,6 +9316,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 		case KF_ARG_PTR_TO_RB_NODE:
 		case KF_ARG_PTR_TO_MEM:
 		case KF_ARG_PTR_TO_MEM_SIZE:
+		case KF_ARG_PTR_TO_CALLBACK:
 			/* Trusted by default */
 			break;
 		default:
@@ -9357,6 +9468,9 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 			/* Skip next '__sz' argument */
 			i++;
 			break;
+		case KF_ARG_PTR_TO_CALLBACK:
+			meta->subprogno = reg->subprogno;
+			break;
 		}
 	}
 
@@ -9477,6 +9591,16 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 		}
 	}
 
+	if (meta.func_id == special_kfunc_list[KF_bpf_rbtree_add]) {
+		err = __check_func_call(env, insn, insn_idx_p, meta.subprogno,
+					set_rbtree_add_callback_state);
+		if (err) {
+			verbose(env, "kfunc %s#%d failed callback verification\n",
+				func_name, func_id);
+			return err;
+		}
+	}
+
 	for (i = 0; i < CALLER_SAVED_REGS; i++)
 		mark_reg_not_init(env, regs, caller_saved[i]);
 
@@ -14309,7 +14433,8 @@ static int do_check(struct bpf_verifier_env *env)
 					return -EINVAL;
 				}
 
-				if (env->cur_state->active_lock.ptr) {
+				if (env->cur_state->active_lock.ptr &&
+				    !in_rbtree_lock_required_cb(env)) {
 					verbose(env, "bpf_spin_unlock is missing\n");
 					return -EINVAL;
 				}
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 09/13] bpf: Special verifier handling for bpf_rbtree_{remove, first}
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (7 preceding siblings ...)
  2022-12-17  8:25 ` [PATCH v2 bpf-next 08/13] bpf: Add callback validation to kfunc verifier logic Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-29  4:02   ` Alexei Starovoitov
  2022-12-17  8:25 ` [PATCH v2 bpf-next 10/13] bpf: Add bpf_rbtree_{add,remove,first} decls to bpf_experimental.h Dave Marchevsky
                   ` (3 subsequent siblings)
  12 siblings, 1 reply; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

Newly-added bpf_rbtree_{remove,first} kfuncs have some special properties
that require handling in the verifier:

  * both bpf_rbtree_remove and bpf_rbtree_first return the type containing
    the bpf_rb_node field, with the offset set to that field's offset,
    instead of a struct bpf_rb_node *
    * mark_reg_graph_node helper added in previous patch generalizes
      this logic, use it

  * bpf_rbtree_remove's node input is a node that's been inserted
    in the tree - a non-owning reference.

  * bpf_rbtree_remove must invalidate non-owning references in order to
    avoid aliasing issue. Add KF_INVALIDATE_NON_OWN flag, which
    indicates that the marked kfunc is a non-owning ref invalidation
    point, and associated verifier logic using previously-added
    invalidate_non_owning_refs helper.

  * Unlike other functions, which convert one of their input arg regs to
    non-owning reference, bpf_rbtree_first takes no arguments and just
    returns a non-owning reference (possibly null)
    * For now verifier logic for this is special-cased instead of
      adding new kfunc flag.

This patch, along with the previous one, complete special verifier
handling for all rbtree API functions added in this series.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 include/linux/btf.h   |  1 +
 kernel/bpf/helpers.c  |  2 +-
 kernel/bpf/verifier.c | 34 ++++++++++++++++++++++++++++------
 3 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/include/linux/btf.h b/include/linux/btf.h
index 8aee3f7f4248..3663911bb7c0 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -72,6 +72,7 @@
 #define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
 #define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
 #define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
+#define KF_INVALIDATE_NON_OWN	(1 << 9) /* kfunc invalidates non-owning refs after return */
 
 /*
  * Return the name of the passed struct, if exists, or halt the build if for
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index de4523c777b7..0e6d010e6423 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -2121,7 +2121,7 @@ BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
 BTF_ID_FLAGS(func, bpf_task_acquire_not_zero, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_task_kptr_get, KF_ACQUIRE | KF_KPTR_GET | KF_RET_NULL)
 BTF_ID_FLAGS(func, bpf_task_release, KF_RELEASE)
-BTF_ID_FLAGS(func, bpf_rbtree_remove, KF_ACQUIRE)
+BTF_ID_FLAGS(func, bpf_rbtree_remove, KF_ACQUIRE | KF_INVALIDATE_NON_OWN)
 BTF_ID_FLAGS(func, bpf_rbtree_add, KF_RELEASE | KF_RELEASE_NON_OWN)
 BTF_ID_FLAGS(func, bpf_rbtree_first, KF_RET_NULL)
 
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 75979f78399d..b4bf3701de7f 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -8393,6 +8393,11 @@ static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
 	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
 }
 
+static bool is_kfunc_invalidate_non_own(struct bpf_kfunc_call_arg_meta *meta)
+{
+	return meta->kfunc_flags & KF_INVALIDATE_NON_OWN;
+}
+
 static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
 {
 	return meta->kfunc_flags & KF_TRUSTED_ARGS;
@@ -9425,10 +9430,20 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 				verbose(env, "arg#%d expected pointer to allocated object\n", i);
 				return -EINVAL;
 			}
-			if (!reg->ref_obj_id) {
+			if (meta->func_id == special_kfunc_list[KF_bpf_rbtree_remove]) {
+				if (reg->ref_obj_id) {
+					verbose(env, "rbtree_remove node input must be non-owning ref\n");
+					return -EINVAL;
+				}
+				if (in_rbtree_lock_required_cb(env)) {
+					verbose(env, "rbtree_remove not allowed in rbtree cb\n");
+					return -EINVAL;
+				}
+			} else if (!reg->ref_obj_id) {
 				verbose(env, "allocated object must be referenced\n");
 				return -EINVAL;
 			}
+
 			ret = process_kf_arg_ptr_to_rbtree_node(env, reg, regno, meta);
 			if (ret < 0)
 				return ret;
@@ -9665,11 +9680,12 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 				   meta.func_id == special_kfunc_list[KF_bpf_list_pop_back]) {
 				struct btf_field *field = meta.arg_list_head.field;
 
-				mark_reg_known_zero(env, regs, BPF_REG_0);
-				regs[BPF_REG_0].type = PTR_TO_BTF_ID | MEM_ALLOC;
-				regs[BPF_REG_0].btf = field->graph_root.btf;
-				regs[BPF_REG_0].btf_id = field->graph_root.value_btf_id;
-				regs[BPF_REG_0].off = field->graph_root.node_offset;
+				mark_reg_graph_node(regs, BPF_REG_0, &field->graph_root);
+			} else if (meta.func_id == special_kfunc_list[KF_bpf_rbtree_remove] ||
+				   meta.func_id == special_kfunc_list[KF_bpf_rbtree_first]) {
+				struct btf_field *field = meta.arg_rbtree_root.field;
+
+				mark_reg_graph_node(regs, BPF_REG_0, &field->graph_root);
 			} else if (meta.func_id == special_kfunc_list[KF_bpf_cast_to_kern_ctx]) {
 				mark_reg_known_zero(env, regs, BPF_REG_0);
 				regs[BPF_REG_0].type = PTR_TO_BTF_ID | PTR_TRUSTED;
@@ -9735,7 +9751,13 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
 			if (is_kfunc_ret_null(&meta))
 				regs[BPF_REG_0].id = id;
 			regs[BPF_REG_0].ref_obj_id = id;
+		} else if (meta.func_id == special_kfunc_list[KF_bpf_rbtree_first]) {
+			ref_set_non_owning_lock(env, &regs[BPF_REG_0]);
 		}
+
+		if (is_kfunc_invalidate_non_own(&meta))
+			invalidate_non_owning_refs(env, &env->cur_state->active_lock);
+
 		if (reg_may_point_to_spin_lock(&regs[BPF_REG_0]) && !regs[BPF_REG_0].id)
 			regs[BPF_REG_0].id = ++env->id_gen;
 	} /* else { add_kfunc_call() ensures it is btf_type_is_void(t) } */
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 10/13] bpf: Add bpf_rbtree_{add,remove,first} decls to bpf_experimental.h
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (8 preceding siblings ...)
  2022-12-17  8:25 ` [PATCH v2 bpf-next 09/13] bpf: Special verifier handling for bpf_rbtree_{remove, first} Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-17  8:25 ` [PATCH v2 bpf-next 11/13] libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj type Dave Marchevsky
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

These kfuncs will be used by selftests in following patches

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 .../testing/selftests/bpf/bpf_experimental.h  | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tools/testing/selftests/bpf/bpf_experimental.h b/tools/testing/selftests/bpf/bpf_experimental.h
index 424f7bbbfe9b..dbd2c729781a 100644
--- a/tools/testing/selftests/bpf/bpf_experimental.h
+++ b/tools/testing/selftests/bpf/bpf_experimental.h
@@ -65,4 +65,28 @@ extern struct bpf_list_node *bpf_list_pop_front(struct bpf_list_head *head) __ks
  */
 extern struct bpf_list_node *bpf_list_pop_back(struct bpf_list_head *head) __ksym;
 
+/* Description
+ *	Remove 'node' from rbtree with root 'root'
+ * Returns
+ * 	Pointer to the removed node, or NULL if 'root' didn't contain 'node'
+ */
+extern struct bpf_rb_node *bpf_rbtree_remove(struct bpf_rb_root *root,
+					     struct bpf_rb_node *node) __ksym;
+
+/* Description
+ *	Add 'node' to rbtree with root 'root' using comparator 'less'
+ * Returns
+ *	Nothing
+ */
+extern void bpf_rbtree_add(struct bpf_rb_root *root, struct bpf_rb_node *node,
+			   bool (less)(struct bpf_rb_node *a, const struct bpf_rb_node *b)) __ksym;
+
+/* Description
+ *	Return the first (leftmost) node in input tree
+ * Returns
+ *	Pointer to the node, which is _not_ removed from the tree. If the tree
+ *	contains no nodes, returns NULL.
+ */
+extern struct bpf_rb_node *bpf_rbtree_first(struct bpf_rb_root *root) __ksym;
+
 #endif
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 11/13] libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj type
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (9 preceding siblings ...)
  2022-12-17  8:25 ` [PATCH v2 bpf-next 10/13] bpf: Add bpf_rbtree_{add,remove,first} decls to bpf_experimental.h Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-22 18:50   ` Andrii Nakryiko
  2022-12-17  8:25 ` [PATCH v2 bpf-next 12/13] selftests/bpf: Add rbtree selftests Dave Marchevsky
  2022-12-17  8:25 ` [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs Dave Marchevsky
  12 siblings, 1 reply; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

If a BPF program defines a struct or union type which has a field type
that the verifier considers special - spin_lock, graph datastructure
heads and nodes - the verifier needs to be able to find fields of that
type using BTF.

For such a program, BTF is required, so modify kernel_needs_btf helper
to ensure that correct "BTF is mandatory" error message is emitted.

The newly-added btf_has_alloc_obj_type looks for BTF_KIND_STRUCTs with a
name corresponding to a special type. If any such struct is found it is
assumed that some variable is using it, and therefore that successful
BTF load is necessary.

Also add a kernel_needs_btf check to bpf_object__create_map where it was
previously missing. When this function calls bpf_map_create, kernel may
reject map creation due to mismatched graph owner and ownee
types (e.g. a struct bpf_list_head with __contains tag pointing to
bpf_rbtree_node field). In such a scenario - or any other where BTF is
necessary for verification - bpf_map_create should not be retried
without BTF.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 tools/lib/bpf/libbpf.c | 50 ++++++++++++++++++++++++++++++++----------
 1 file changed, 39 insertions(+), 11 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2a82f49ce16f..56a905b502c9 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -998,6 +998,31 @@ find_struct_ops_kern_types(const struct btf *btf, const char *tname,
 	return 0;
 }
 
+/* Should match alloc_obj_fields in kernel/bpf/btf.c
+ */
+static const char *alloc_obj_fields[] = {
+	"bpf_spin_lock",
+	"bpf_list_head",
+	"bpf_list_node",
+	"bpf_rb_root",
+	"bpf_rb_node",
+};
+
+static bool
+btf_has_alloc_obj_type(const struct btf *btf)
+{
+	const char *tname;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(alloc_obj_fields); i++) {
+		tname = alloc_obj_fields[i];
+		if (btf__find_by_name_kind(btf, tname, BTF_KIND_STRUCT) > 0)
+			return true;
+	}
+
+	return false;
+}
+
 static bool bpf_map__is_struct_ops(const struct bpf_map *map)
 {
 	return map->def.type == BPF_MAP_TYPE_STRUCT_OPS;
@@ -2794,7 +2819,8 @@ static bool libbpf_needs_btf(const struct bpf_object *obj)
 
 static bool kernel_needs_btf(const struct bpf_object *obj)
 {
-	return obj->efile.st_ops_shndx >= 0;
+	return obj->efile.st_ops_shndx >= 0 ||
+		(obj->btf && btf_has_alloc_obj_type(obj->btf));
 }
 
 static int bpf_object__init_btf(struct bpf_object *obj,
@@ -5103,16 +5129,18 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
 
 		err = -errno;
 		cp = libbpf_strerror_r(err, errmsg, sizeof(errmsg));
-		pr_warn("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
-			map->name, cp, err);
-		create_attr.btf_fd = 0;
-		create_attr.btf_key_type_id = 0;
-		create_attr.btf_value_type_id = 0;
-		map->btf_key_type_id = 0;
-		map->btf_value_type_id = 0;
-		map->fd = bpf_map_create(def->type, map_name,
-					 def->key_size, def->value_size,
-					 def->max_entries, &create_attr);
+		pr_warn("Error in bpf_create_map_xattr(%s):%s(%d).\n", map->name, cp, err);
+		if (!kernel_needs_btf(obj)) {
+			pr_warn("Retrying bpf_map_create_xattr(%s) without BTF.\n", map->name);
+			create_attr.btf_fd = 0;
+			create_attr.btf_key_type_id = 0;
+			create_attr.btf_value_type_id = 0;
+			map->btf_key_type_id = 0;
+			map->btf_value_type_id = 0;
+			map->fd = bpf_map_create(def->type, map_name,
+						 def->key_size, def->value_size,
+						 def->max_entries, &create_attr);
+		}
 	}
 
 	err = map->fd < 0 ? -errno : 0;
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 12/13] selftests/bpf: Add rbtree selftests
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (10 preceding siblings ...)
  2022-12-17  8:25 ` [PATCH v2 bpf-next 11/13] libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj type Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-17  8:25 ` [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs Dave Marchevsky
  12 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

This patch adds selftests exercising the logic changed/added in the
previous patches in the series. A variety of successful and unsuccessful
rbtree usages are validated:

Success:
  * Add some nodes, let map_value bpf_rbtree_root destructor clean them
    up
  * Add some nodes, remove one using the non-owning ref leftover by
    successful rbtree_add() call
  * Add some nodes, remove one using the non-owning ref returned by
    rbtree_first() call

Failure:
  * BTF where bpf_rb_root owns bpf_list_node should fail to load
  * BTF where node of type X is added to tree containing nodes of type Y
    should fail to load
  * No calling rbtree api functions in 'less' callback for rbtree_add
  * No releasing lock in 'less' callback for rbtree_add
  * No removing a node which hasn't been added to any tree
  * No adding a node which has already been added to a tree
  * No escaping of non-owning references past their lock's
    critical section
  * No escaping of non-owning references past other invalidation points
    (rbtree_remove)

These tests mostly focus on rbtree-specific additions, but some of the
failure cases revalidate scenarios common to both linked_list and rbtree
which are covered in the former's tests. Better to be a bit redundant in
case linked_list and rbtree semantics deviate over time.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 .../testing/selftests/bpf/prog_tests/rbtree.c | 186 +++++++++++
 tools/testing/selftests/bpf/progs/rbtree.c    | 176 +++++++++++
 .../progs/rbtree_btf_fail__add_wrong_type.c   |  52 +++
 .../progs/rbtree_btf_fail__wrong_node_type.c  |  49 +++
 .../testing/selftests/bpf/progs/rbtree_fail.c | 296 ++++++++++++++++++
 5 files changed, 759 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/rbtree.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree_btf_fail__add_wrong_type.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree_btf_fail__wrong_node_type.c
 create mode 100644 tools/testing/selftests/bpf/progs/rbtree_fail.c

diff --git a/tools/testing/selftests/bpf/prog_tests/rbtree.c b/tools/testing/selftests/bpf/prog_tests/rbtree.c
new file mode 100644
index 000000000000..ae332a532223
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/rbtree.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */
+
+#include <test_progs.h>
+#include <network_helpers.h>
+
+#include "rbtree.skel.h"
+#include "rbtree_fail.skel.h"
+#include "rbtree_btf_fail__wrong_node_type.skel.h"
+#include "rbtree_btf_fail__add_wrong_type.skel.h"
+
+static char log_buf[1024 * 1024];
+
+static struct {
+	const char *prog_name;
+	const char *err_msg;
+} rbtree_fail_tests[] = {
+	{"rbtree_api_nolock_add", "bpf_spin_lock at off=16 must be held for bpf_rb_root"},
+	{"rbtree_api_nolock_remove", "bpf_spin_lock at off=16 must be held for bpf_rb_root"},
+	{"rbtree_api_nolock_first", "bpf_spin_lock at off=16 must be held for bpf_rb_root"},
+
+	/* Specific failure string for these three isn't very important, but it shouldn't be
+	 * possible to call rbtree api func from within add() callback
+	 */
+	{"rbtree_api_add_bad_cb_bad_fn_call_add",
+	 "release kernel function bpf_rbtree_add expects refcounted PTR_TO_BTF_ID"},
+	{"rbtree_api_add_bad_cb_bad_fn_call_remove", "rbtree_remove not allowed in rbtree cb"},
+	{"rbtree_api_add_bad_cb_bad_fn_call_first_unlock_after",
+	 "can't spin_{lock,unlock} in rbtree cb"},
+
+	{"rbtree_api_remove_unadded_node", "rbtree_remove node input must be non-owning ref"},
+	{"rbtree_api_add_to_multiple_trees",
+	 "function bpf_rbtree_add expects refcounted PTR_TO_BTF_ID"},
+	{"rbtree_api_add_release_unlock_escape", "arg#1 expected pointer to allocated object"},
+	{"rbtree_api_first_release_unlock_escape", "arg#1 expected pointer to allocated object"},
+	{"rbtree_api_remove_no_drop", "Unreleased reference id=2 alloc_insn=11"},
+	{"rbtree_api_release_aliasing", "arg#1 expected pointer to allocated object"},
+};
+
+static void test_rbtree_fail_prog(const char *prog_name, const char *err_msg)
+{
+	LIBBPF_OPTS(bpf_object_open_opts, opts,
+		    .kernel_log_buf = log_buf,
+		    .kernel_log_size = sizeof(log_buf),
+		    .kernel_log_level = 1
+	);
+	struct rbtree_fail *skel;
+	struct bpf_program *prog;
+	int ret;
+
+	skel = rbtree_fail__open_opts(&opts);
+	if (!ASSERT_OK_PTR(skel, "rbtree_fail__open_opts"))
+		return;
+
+	prog = bpf_object__find_program_by_name(skel->obj, prog_name);
+	if (!ASSERT_OK_PTR(prog, "bpf_object__find_program_by_name"))
+		goto end;
+
+	bpf_program__set_autoload(prog, true);
+
+	ret = rbtree_fail__load(skel);
+	if (!ASSERT_ERR(ret, "rbtree_fail__load must fail"))
+		goto end;
+
+	if (!ASSERT_OK_PTR(strstr(log_buf, err_msg), "expected error message")) {
+		fprintf(stderr, "Expected: %s\n", err_msg);
+		fprintf(stderr, "Verifier: %s\n", log_buf);
+	}
+
+end:
+	rbtree_fail__destroy(skel);
+}
+
+static void test_rbtree_add_nodes(void)
+{
+	LIBBPF_OPTS(bpf_test_run_opts, opts,
+		    .data_in = &pkt_v4,
+		    .data_size_in = sizeof(pkt_v4),
+		    .repeat = 1,
+	);
+	struct rbtree *skel;
+	int ret;
+
+	skel = rbtree__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "rbtree__open_and_load"))
+		return;
+
+	ret = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.rbtree_add_nodes), &opts);
+	ASSERT_OK(ret, "rbtree_add_nodes run");
+	ASSERT_OK(opts.retval, "rbtree_add_nodes retval");
+	ASSERT_EQ(skel->data->less_callback_ran, 1, "rbtree_add_nodes less_callback_ran");
+
+	rbtree__destroy(skel);
+}
+
+static void test_rbtree_add_and_remove(void)
+{
+	LIBBPF_OPTS(bpf_test_run_opts, opts,
+		    .data_in = &pkt_v4,
+		    .data_size_in = sizeof(pkt_v4),
+		    .repeat = 1,
+	);
+	struct rbtree *skel;
+	int ret;
+
+	skel = rbtree__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "rbtree__open_and_load"))
+		return;
+
+	ret = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.rbtree_add_and_remove), &opts);
+	ASSERT_OK(ret, "rbtree_add_and_remove");
+	ASSERT_OK(opts.retval, "rbtree_add_and_remove retval");
+	ASSERT_EQ(skel->data->removed_key, 5, "rbtree_add_and_remove first removed key");
+
+	rbtree__destroy(skel);
+}
+
+static void test_rbtree_first_and_remove(void)
+{
+	LIBBPF_OPTS(bpf_test_run_opts, opts,
+		    .data_in = &pkt_v4,
+		    .data_size_in = sizeof(pkt_v4),
+		    .repeat = 1,
+	);
+	struct rbtree *skel;
+	int ret;
+
+	skel = rbtree__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "rbtree__open_and_load"))
+		return;
+
+	ret = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.rbtree_first_and_remove), &opts);
+	ASSERT_OK(ret, "rbtree_first_and_remove");
+	ASSERT_OK(opts.retval, "rbtree_first_and_remove retval");
+	ASSERT_EQ(skel->data->first_data[0], 2, "rbtree_first_and_remove first rbtree_first()");
+	ASSERT_EQ(skel->data->removed_key, 1, "rbtree_first_and_remove first removed key");
+	ASSERT_EQ(skel->data->first_data[1], 4, "rbtree_first_and_remove second rbtree_first()");
+
+	rbtree__destroy(skel);
+}
+
+void test_rbtree_success(void)
+{
+	if (test__start_subtest("rbtree_add_nodes"))
+		test_rbtree_add_nodes();
+	if (test__start_subtest("rbtree_add_and_remove"))
+		test_rbtree_add_and_remove();
+	if (test__start_subtest("rbtree_first_and_remove"))
+		test_rbtree_first_and_remove();
+}
+
+#define BTF_FAIL_TEST(suffix)									\
+void test_rbtree_btf_fail__##suffix(void)							\
+{												\
+	struct rbtree_btf_fail__##suffix *skel;							\
+												\
+	skel = rbtree_btf_fail__##suffix##__open_and_load();					\
+	if (!ASSERT_ERR_PTR(skel,								\
+			    "rbtree_btf_fail__" #suffix "__open_and_load unexpected success"))	\
+		rbtree_btf_fail__##suffix##__destroy(skel);					\
+}
+
+#define RUN_BTF_FAIL_TEST(suffix)				\
+	if (test__start_subtest("rbtree_btf_fail__" #suffix))	\
+		test_rbtree_btf_fail__##suffix();
+
+BTF_FAIL_TEST(wrong_node_type);
+BTF_FAIL_TEST(add_wrong_type);
+
+void test_rbtree_btf_fail(void)
+{
+	RUN_BTF_FAIL_TEST(wrong_node_type);
+	RUN_BTF_FAIL_TEST(add_wrong_type);
+}
+
+void test_rbtree_fail(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(rbtree_fail_tests); i++) {
+		if (!test__start_subtest(rbtree_fail_tests[i].prog_name))
+			continue;
+		test_rbtree_fail_prog(rbtree_fail_tests[i].prog_name,
+				      rbtree_fail_tests[i].err_msg);
+	}
+}
diff --git a/tools/testing/selftests/bpf/progs/rbtree.c b/tools/testing/selftests/bpf/progs/rbtree.c
new file mode 100644
index 000000000000..e5db1a4287e5
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/rbtree.c
@@ -0,0 +1,176 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */
+
+#include <vmlinux.h>
+#include <bpf/bpf_tracing.h>
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_core_read.h>
+#include "bpf_experimental.h"
+
+struct node_data {
+	long key;
+	long data;
+	struct bpf_rb_node node;
+};
+
+long less_callback_ran = -1;
+long removed_key = -1;
+long first_data[2] = {-1, -1};
+
+#define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
+private(A) struct bpf_spin_lock glock;
+private(A) struct bpf_rb_root groot __contains(node_data, node);
+
+static bool less(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data *node_a;
+	struct node_data *node_b;
+
+	node_a = container_of(a, struct node_data, node);
+	node_b = container_of(b, struct node_data, node);
+	less_callback_ran = 1;
+
+	return node_a->key < node_b->key;
+}
+
+static long __add_three(struct bpf_rb_root *root, struct bpf_spin_lock *lock)
+{
+	struct node_data *n, *m;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+	n->key = 5;
+
+	m = bpf_obj_new(typeof(*m));
+	if (!m) {
+		bpf_obj_drop(n);
+		return 2;
+	}
+	m->key = 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_rbtree_add(&groot, &m->node, less);
+	bpf_spin_unlock(&glock);
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 3;
+	n->key = 3;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+SEC("tc")
+long rbtree_add_nodes(void *ctx)
+{
+	return __add_three(&groot, &glock);
+}
+
+SEC("tc")
+long rbtree_add_and_remove(void *ctx)
+{
+	struct bpf_rb_node *res = NULL;
+	struct node_data *n, *m;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		goto err_out;
+	n->key = 5;
+
+	m = bpf_obj_new(typeof(*m));
+	if (!m)
+		goto err_out;
+	m->key = 3;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_rbtree_add(&groot, &m->node, less);
+	res = bpf_rbtree_remove(&groot, &n->node);
+	bpf_spin_unlock(&glock);
+
+	n = container_of(res, struct node_data, node);
+	removed_key = n->key;
+
+	bpf_obj_drop(n);
+
+	return 0;
+err_out:
+	if (n)
+		bpf_obj_drop(n);
+	if (m)
+		bpf_obj_drop(m);
+	return 1;
+}
+
+SEC("tc")
+long rbtree_first_and_remove(void *ctx)
+{
+	struct bpf_rb_node *res = NULL;
+	struct node_data *n, *m, *o;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+	n->key = 3;
+	n->data = 4;
+
+	m = bpf_obj_new(typeof(*m));
+	if (!m)
+		goto err_out;
+	m->key = 5;
+	m->data = 6;
+
+	o = bpf_obj_new(typeof(*o));
+	if (!o)
+		goto err_out;
+	o->key = 1;
+	o->data = 2;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_rbtree_add(&groot, &m->node, less);
+	bpf_rbtree_add(&groot, &o->node, less);
+
+	res = bpf_rbtree_first(&groot);
+	if (!res) {
+		bpf_spin_unlock(&glock);
+		return 2;
+	}
+
+	o = container_of(res, struct node_data, node);
+	first_data[0] = o->data;
+
+	res = bpf_rbtree_remove(&groot, &o->node);
+	bpf_spin_unlock(&glock);
+
+	o = container_of(res, struct node_data, node);
+	removed_key = o->key;
+
+	bpf_obj_drop(o);
+
+	bpf_spin_lock(&glock);
+	res = bpf_rbtree_first(&groot);
+	if (!res) {
+		bpf_spin_unlock(&glock);
+		return 3;
+	}
+
+	o = container_of(res, struct node_data, node);
+	first_data[1] = o->data;
+	bpf_spin_unlock(&glock);
+
+	return 0;
+err_out:
+	if (n)
+		bpf_obj_drop(n);
+	if (m)
+		bpf_obj_drop(m);
+	return 1;
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/tools/testing/selftests/bpf/progs/rbtree_btf_fail__add_wrong_type.c b/tools/testing/selftests/bpf/progs/rbtree_btf_fail__add_wrong_type.c
new file mode 100644
index 000000000000..60079b202c07
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/rbtree_btf_fail__add_wrong_type.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */
+
+#include <vmlinux.h>
+#include <bpf/bpf_tracing.h>
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_core_read.h>
+#include "bpf_experimental.h"
+
+struct node_data {
+	int key;
+	int data;
+	struct bpf_rb_node node;
+};
+
+struct node_data2 {
+	int key;
+	struct bpf_rb_node node;
+	int data;
+};
+
+static bool less2(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data2 *node_a;
+	struct node_data2 *node_b;
+
+	node_a = container_of(a, struct node_data2, node);
+	node_b = container_of(b, struct node_data2, node);
+
+	return node_a->key < node_b->key;
+}
+
+#define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
+private(A) struct bpf_spin_lock glock;
+private(A) struct bpf_rb_root groot __contains(node_data, node);
+
+SEC("tc")
+long rbtree_api_add__add_wrong_type(void *ctx)
+{
+	struct node_data2 *n;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less2);
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/tools/testing/selftests/bpf/progs/rbtree_btf_fail__wrong_node_type.c b/tools/testing/selftests/bpf/progs/rbtree_btf_fail__wrong_node_type.c
new file mode 100644
index 000000000000..340f97da1084
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/rbtree_btf_fail__wrong_node_type.c
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */
+
+#include <vmlinux.h>
+#include <bpf/bpf_tracing.h>
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_core_read.h>
+#include "bpf_experimental.h"
+
+/* BTF load should fail as bpf_rb_root __contains this type and points to
+ * 'node', but 'node' is not a bpf_rb_node
+ */
+struct node_data {
+	int key;
+	int data;
+	struct bpf_list_node node;
+};
+
+static bool less(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data *node_a;
+	struct node_data *node_b;
+
+	node_a = container_of(a, struct node_data, node);
+	node_b = container_of(b, struct node_data, node);
+
+	return node_a->key < node_b->key;
+}
+
+#define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
+private(A) struct bpf_spin_lock glock;
+private(A) struct bpf_rb_root groot __contains(node_data, node);
+
+SEC("tc")
+long rbtree_api_add__wrong_node_type(void *ctx)
+{
+	struct node_data *n;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_first(&groot);
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/tools/testing/selftests/bpf/progs/rbtree_fail.c b/tools/testing/selftests/bpf/progs/rbtree_fail.c
new file mode 100644
index 000000000000..df6e2a39fcee
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/rbtree_fail.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <vmlinux.h>
+#include <bpf/bpf_tracing.h>
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_core_read.h>
+#include "bpf_experimental.h"
+
+struct node_data {
+	long key;
+	long data;
+	struct bpf_rb_node node;
+};
+
+#define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
+private(A) struct bpf_spin_lock glock;
+private(A) struct bpf_rb_root groot __contains(node_data, node);
+private(A) struct bpf_rb_root groot2 __contains(node_data, node);
+
+static bool less(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data *node_a;
+	struct node_data *node_b;
+
+	node_a = container_of(a, struct node_data, node);
+	node_b = container_of(b, struct node_data, node);
+
+	return node_a->key < node_b->key;
+}
+
+SEC("?tc")
+long rbtree_api_nolock_add(void *ctx)
+{
+	struct node_data *n;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_rbtree_add(&groot, &n->node, less);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_nolock_remove(void *ctx)
+{
+	struct node_data *n;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_spin_unlock(&glock);
+
+	bpf_rbtree_remove(&groot, &n->node);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_nolock_first(void *ctx)
+{
+	bpf_rbtree_first(&groot);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_remove_unadded_node(void *ctx)
+{
+	struct node_data *n, *m;
+	struct bpf_rb_node *res;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	m = bpf_obj_new(typeof(*m));
+	if (!m) {
+		bpf_obj_drop(n);
+		return 1;
+	}
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+
+	/* This remove should pass verifier */
+	res = bpf_rbtree_remove(&groot, &n->node);
+	n = container_of(res, struct node_data, node);
+
+	/* This remove shouldn't, m isn't in an rbtree */
+	res = bpf_rbtree_remove(&groot, &m->node);
+	m = container_of(res, struct node_data, node);
+	bpf_spin_unlock(&glock);
+
+	if (n)
+		bpf_obj_drop(n);
+	if (m)
+		bpf_obj_drop(m);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_remove_no_drop(void *ctx)
+{
+	struct bpf_rb_node *res;
+	struct node_data *n;
+
+	bpf_spin_lock(&glock);
+	res = bpf_rbtree_first(&groot);
+	if (!res)
+		goto unlock_err;
+
+	res = bpf_rbtree_remove(&groot, res);
+
+	n = container_of(res, struct node_data, node);
+	bpf_spin_unlock(&glock);
+
+	/* bpf_obj_drop(n) is missing here */
+	return 0;
+
+unlock_err:
+	bpf_spin_unlock(&glock);
+	return 1;
+}
+
+SEC("?tc")
+long rbtree_api_add_to_multiple_trees(void *ctx)
+{
+	struct node_data *n;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+
+	/* This add should fail since n already in groot's tree */
+	bpf_rbtree_add(&groot2, &n->node, less);
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_add_release_unlock_escape(void *ctx)
+{
+	struct node_data *n;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_spin_unlock(&glock);
+
+	bpf_spin_lock(&glock);
+	/* After add() in previous critical section, n should be
+	 * release_on_unlock and released after previous spin_unlock,
+	 * so should not be possible to use it here
+	 */
+	bpf_rbtree_remove(&groot, &n->node);
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_release_aliasing(void *ctx)
+{
+	struct node_data *n, *m, *o;
+	struct bpf_rb_node *res;
+
+	n = bpf_obj_new(typeof(*n));
+	if (!n)
+		return 1;
+
+	bpf_spin_lock(&glock);
+	bpf_rbtree_add(&groot, &n->node, less);
+	bpf_spin_unlock(&glock);
+
+	bpf_spin_lock(&glock);
+
+	/* m and o point to the same node,
+	 * but verifier doesn't know this
+	 */
+	res = bpf_rbtree_first(&groot);
+	if (!res)
+		return 1;
+	o = container_of(res, struct node_data, node);
+
+	res = bpf_rbtree_first(&groot);
+	if (!res)
+		return 1;
+	m = container_of(res, struct node_data, node);
+
+	bpf_rbtree_remove(&groot, &m->node);
+	/* This second remove shouldn't be possible. Retval of previous
+	 * remove returns owning reference to m, which is the same
+	 * node o's non-owning ref is pointing at
+	 *
+	 * In order to preserve property
+	 *   * owning ref must not be in rbtree
+	 *   * non-owning ref must be in rbtree
+	 *
+	 * o's ref must be invalidated after previous remove. Otherwise
+	 * we'd have non-owning ref to node that isn't in rbtree, and
+	 * verifier wouldn't be able to use type system to prevent remove
+	 * of ref that already isn't in any tree. Would have to do runtime
+	 * checks in that case.
+	 */
+	bpf_rbtree_remove(&groot, &o->node);
+
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+SEC("?tc")
+long rbtree_api_first_release_unlock_escape(void *ctx)
+{
+	struct bpf_rb_node *res;
+	struct node_data *n;
+
+	bpf_spin_lock(&glock);
+	res = bpf_rbtree_first(&groot);
+	if (res)
+		n = container_of(res, struct node_data, node);
+	bpf_spin_unlock(&glock);
+
+	bpf_spin_lock(&glock);
+	/* After first() in previous critical section, n should be
+	 * release_on_unlock and released after previous spin_unlock,
+	 * so should not be possible to use it here
+	 */
+	bpf_rbtree_remove(&groot, &n->node);
+	bpf_spin_unlock(&glock);
+	return 0;
+}
+
+static bool less__bad_fn_call_add(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data *node_a;
+	struct node_data *node_b;
+
+	node_a = container_of(a, struct node_data, node);
+	node_b = container_of(b, struct node_data, node);
+	bpf_rbtree_add(&groot, &node_a->node, less);
+
+	return node_a->key < node_b->key;
+}
+
+static bool less__bad_fn_call_remove(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data *node_a;
+	struct node_data *node_b;
+
+	node_a = container_of(a, struct node_data, node);
+	node_b = container_of(b, struct node_data, node);
+	bpf_rbtree_remove(&groot, &node_a->node);
+
+	return node_a->key < node_b->key;
+}
+
+static bool less__bad_fn_call_first_unlock_after(struct bpf_rb_node *a, const struct bpf_rb_node *b)
+{
+	struct node_data *node_a;
+	struct node_data *node_b;
+
+	node_a = container_of(a, struct node_data, node);
+	node_b = container_of(b, struct node_data, node);
+	bpf_rbtree_first(&groot);
+	bpf_spin_unlock(&glock);
+
+	return node_a->key < node_b->key;
+}
+
+#define RBTREE_API_ADD_BAD_CB(cb_suffix)				\
+SEC("?tc")								\
+long rbtree_api_add_bad_cb_##cb_suffix(void *ctx)			\
+{									\
+	struct node_data *n;						\
+									\
+	n = bpf_obj_new(typeof(*n));					\
+	if (!n)								\
+		return 1;						\
+									\
+	bpf_spin_lock(&glock);						\
+	bpf_rbtree_add(&groot, &n->node, less__##cb_suffix);		\
+	bpf_spin_unlock(&glock);					\
+	return 0;							\
+}
+
+RBTREE_API_ADD_BAD_CB(bad_fn_call_add);
+RBTREE_API_ADD_BAD_CB(bad_fn_call_remove);
+RBTREE_API_ADD_BAD_CB(bad_fn_call_first_unlock_after);
+
+char _license[] SEC("license") = "GPL";
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs
  2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
                   ` (11 preceding siblings ...)
  2022-12-17  8:25 ` [PATCH v2 bpf-next 12/13] selftests/bpf: Add rbtree selftests Dave Marchevsky
@ 2022-12-17  8:25 ` Dave Marchevsky
  2022-12-28 21:26   ` David Vernet
  12 siblings, 1 reply; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  8:25 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo, Dave Marchevsky

It is difficult to intuit the semantics of owning and non-owning
references from verifier code. In order to keep the high-level details
from being lost in the mailing list, this patch adds documentation
explaining semantics and details.

The target audience of doc added in this patch is folks working on BPF
internals, as there's focus on "what should the verifier do here". Via
reorganization or copy-and-paste, much of the content can probably be
repurposed for BPF program writer audience as well.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
---
 Documentation/bpf/graph_ds_impl.rst | 208 ++++++++++++++++++++++++++++
 Documentation/bpf/other.rst         |   3 +-
 2 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/bpf/graph_ds_impl.rst

diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
new file mode 100644
index 000000000000..f92cbd223dc3
--- /dev/null
+++ b/Documentation/bpf/graph_ds_impl.rst
@@ -0,0 +1,208 @@
+=========================
+BPF Graph Data Structures
+=========================
+
+This document describes implementation details of new-style "graph" data
+structures (linked_list, rbtree), with particular focus on verifier
+implementation of semantics particular to those data structures.
+
+Note that the intent of this document is to describe the current state of
+these graph data structures, **no guarantees** of stability for either
+semantics or APIs are made or implied here.
+
+.. contents::
+    :local:
+    :depth: 2
+
+Introduction
+------------
+
+The BPF map API has historically been the main way to expose data structures
+of various types for use within BPF programs. Some data structures fit naturally
+with the map API (HASH, ARRAY), others less so. Consequentially, programs
+interacting with the latter group of data structures can be hard to parse
+for kernel programmers without previous BPF experience.
+
+Luckily, some restrictions which necessitated the use of BPF map semantics are
+no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
+BPF allocator, it is now possible to implement BPF data structures whose API
+and semantics more closely match those exposed to the rest of the kernel.
+
+Two such data structures - linked_list and rbtree - have many verification
+details in common. Because both have "root"s ("head" for linked_list) and
+"node"s, the verifier code and this document refer to common functionality
+as "graph_api", "graph_root", "graph_node", etc.
+
+Unless otherwise stated, examples and semantics below apply to both graph data
+structures.
+
+Non-owning references
+---------------------
+
+**Motivation**
+
+Consider the following BPF code:
+
+.. code-block:: c
+        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
+
+        bpf_spin_lock(&lock);
+
+        bpf_rbtree_add(&tree, n); /* AFTER */
+
+        bpf_spin_unlock(&lock);
+----
+
+From the verifier's perspective, after bpf_obj_new ``n`` has type
+``PTR_TO_BTF_ID | MEM_ALLOC`` with btf_id of ``struct node_data`` and a
+nonzero ``ref_obj_id``. Because it holds ``n``, the program has ownership
+of the pointee's lifetime (object pointed to by ``n``). The BPF program must
+pass off ownership before exiting - either via ``bpf_obj_drop``, which free's
+the object, or by adding it to ``tree`` with ``bpf_rbtree_add``.
+
+(``BEFORE`` and ``AFTER`` comments in the example denote beginning of "before
+ownership is passed" and "after ownership is passed")
+
+What should the verifier do with ``n`` after ownership is passed off? If the
+object was free'd with ``bpf_obj_drop`` the answer is obvious: the verifier
+should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as
+the object is no longer valid. The underlying memory may have been reused for
+some other allocation, unmapped, etc.
+
+When ownership is passed to ``tree`` via ``bpf_rbtree_add`` the answer is less
+obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
+but that would result in programs with useful, common coding patterns being
+rejected, e.g.:
+
+.. code-block:: c
+        int x;
+        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
+
+        bpf_spin_lock(&lock);
+
+        bpf_rbtree_add(&tree, n); /* AFTER */
+        x = n->data;
+        n->data = 42;
+
+        bpf_spin_unlock(&lock);
+----
+
+Both the read from and write to ``n->data`` would be rejected. The verifier
+can do better, though, by taking advantage of two details:
+
+  * Graph data structure APIs can only be used when the ``bpf_spin_lock``
+    associated with the graph root is held
+  * Both graph data structures have pointer stability
+    * Because graph nodes are allocated with ``bpf_obj_new`` and
+      adding / removing from the root involves fiddling with the
+      ``bpf_{list,rb}_node`` field of the node struct, a graph node will
+      remain at the same address after either operation.
+
+Because the associated ``bpf_spin_lock`` must be held by any program adding
+or removing, if we're in the critical section bounded by that lock, we know
+that no other program can add or remove until the end of the critical section.
+This combined with pointer stability means that, until the critical section
+ends, we can safely access the graph node through ``n`` even after it was used
+to pass ownership.
+
+The verifier considers such a reference a *non-owning reference*. The ref
+returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
+Both terms currently only have meaning in the context of graph nodes and API.
+
+**Details**
+
+Let's enumerate the properties of both types of references.
+
+*owning reference*
+
+  * This reference controls the lifetime of the pointee
+  * Ownership of pointee must be 'released' by passing it to some graph API
+    kfunc, or via ``bpf_obj_drop``, which free's the pointee
+    * If not released before program ends, verifier considers program invalid
+  * Access to the pointee's memory will not page fault
+
+*non-owning reference*
+
+  * This reference does not own the pointee
+    * It cannot be used to add the graph node to a graph root, nor free via
+      ``bpf_obj_drop``
+  * No explicit control of lifetime, but can infer valid lifetime based on
+    non-owning ref existence (see explanation below)
+  * Access to the pointee's memory will not page fault
+
+From verifier's perspective non-owning references can only exist
+between spin_lock and spin_unlock. Why? After spin_unlock another program
+can do arbitrary operations on the data structure like removing and free-ing
+via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,
+free'd, and reused via bpf_obj_new would point to an entirely different thing.
+Or the memory could go away.
+
+To prevent this logic violation all non-owning references are invalidated by
+verifier after critical section ends. This is necessary to ensure "will
+not page fault" property of non-owning reference. So if verifier hasn't
+invalidated a non-owning ref, accessing it will not page fault.
+
+Currently ``bpf_obj_drop`` is not allowed in the critical section, so
+if there's a valid non-owning ref, we must be in critical section, and can
+conclude that the ref's memory hasn't been dropped-and-free'd or dropped-
+and-reused.
+
+Any reference to a node that is in a rbtree _must_ be non-owning, since
+the tree has control of pointee lifetime. Similarly, any ref to a node
+that isn't in rbtree _must_ be owning. This results in a nice property:
+graph API add / remove implementations don't need to check if a node
+has already been added (or already removed), as the verifier type system
+prevents such a state from being valid.
+
+However, pointer aliasing poses an issue for the above "nice property".
+Consider the following example:
+
+.. code-block:: c
+        struct node_data *n, *m, *o, *p;
+        n = bpf_obj_new(typeof(*n));     /* 1 */
+
+        bpf_spin_lock(&lock);
+
+        bpf_rbtree_add(&tree, n);        /* 2 */
+        m = bpf_rbtree_first(&tree);     /* 3 */
+
+        o = bpf_rbtree_remove(&tree, n); /* 4 */
+        p = bpf_rbtree_remove(&tree, m); /* 5 */
+
+        bpf_spin_unlock(&lock);
+
+        bpf_obj_drop(o);
+        bpf_obj_drop(p); /* 6 */
+----
+
+Assume tree is empty before this program runs. If we track verifier state
+changes here using numbers in above comments:
+
+  1) n is an owning reference
+  2) n is a non-owning reference, it's been added to the tree
+  3) n and m are non-owning references, they both point to the same node
+  4) o is an owning reference, n and m non-owning, all point to same node
+  5) o and p are owning, n and m non-owning, all point to the same node
+  6) a double-free has occurred, since o and p point to same node and o was
+     free'd in previous statement
+
+States 4 and 5 violate our "nice property", as there are non-owning refs to
+a node which is not in a rbtree. Statement 5 will try to remove a node which
+has already been removed as a result of this violation. State 6 is a dangerous
+double-free.
+
+At a minimum we should prevent state 6 from being possible. If we can't also
+prevent state 5 then we must abandon our "nice property" and check whether a
+node has already been removed at runtime.
+
+We prevent both by generalizing the "invalidate non-owning references" behavior
+of ``bpf_spin_unlock`` and doing similar invalidation after
+``bpf_rbtree_remove``. The logic here being that any graph API kfunc which:
+
+  * takes an arbitrary node argument
+  * removes it from the datastructure
+  * returns an owning reference to the removed node
+
+May result in a state where some other non-owning reference points to the same
+node. So ``remove``-type kfuncs must be considered a non-owning reference
+invalidation point as well.
diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst
index 3d61963403b4..7e6b12018802 100644
--- a/Documentation/bpf/other.rst
+++ b/Documentation/bpf/other.rst
@@ -6,4 +6,5 @@ Other
    :maxdepth: 1
 
    ringbuf
-   llvm_reloc
\ No newline at end of file
+   llvm_reloc
+   graph_ds_impl
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
@ 2022-12-17  9:21   ` Dave Marchevsky
  2022-12-23 10:51   ` Dan Carpenter
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2022-12-17  9:21 UTC (permalink / raw)
  To: Dave Marchevsky, bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On 12/17/22 3:24 AM, Dave Marchevsky wrote:
> This patch introduces non-owning reference semantics to the verifier,
> specifically linked_list API kfunc handling. release_on_unlock logic for
> refs is refactored - with small functional changes - to implement these
> semantics, and bpf_list_push_{front,back} are migrated to use them.
> 
> When a list node is pushed to a list, the program still has a pointer to
> the node:
> 
>   n = bpf_obj_new(typeof(*n));
> 
>   bpf_spin_lock(&l);
>   bpf_list_push_back(&l, n);
>   /* n still points to the just-added node */
>   bpf_spin_unlock(&l);
> 
> What the verifier considers n to be after the push, and thus what can be
> done with n, are changed by this patch.
> 
> Common properties both before/after this patch:
>   * After push, n is only a valid reference to the node until end of
>     critical section
>   * After push, n cannot be pushed to any list
>   * After push, the program can read the node's fields using n
> 
> Before:
>   * After push, n retains the ref_obj_id which it received on
>     bpf_obj_new, but the associated bpf_reference_state's
>     release_on_unlock field is set to true
>     * release_on_unlock field and associated logic is used to implement
>       "n is only a valid ref until end of critical section"
>   * After push, n cannot be written to, the node must be removed from
>     the list before writing to its fields
>   * After push, n is marked PTR_UNTRUSTED
> 
> After:
>   * After push, n's ref is released and ref_obj_id set to 0. The
>     bpf_reg_state's non_owning_ref_lock struct is populated with the
>     currently active lock
>     * non_owning_ref_lock and logic is used to implement "n is only a
>       valid ref until end of critical section"
>   * n can be written to (except for special fields e.g. bpf_list_node,
>     timer, ...)
>   * No special type flag is added to n after push
> 
> Summary of specific implementation changes to achieve the above:
> 
>   * release_on_unlock field, ref_set_release_on_unlock helper, and logic
>     to "release on unlock" based on that field are removed
> 
>   * The anonymous active_lock struct used by bpf_verifier_state is
>     pulled out into a named struct bpf_active_lock.
> 
>   * A non_owning_ref_lock field of type bpf_active_lock is added to
>     bpf_reg_state's PTR_TO_BTF_ID union
> 
>   * Helpers are added to use non_owning_ref_lock to implement non-owning
>     ref semantics as described above
>     * invalidate_non_owning_refs - helper to clobber all non-owning refs
>       matching a particular bpf_active_lock identity. Replaces
>       release_on_unlock logic in process_spin_lock.
>     * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
>       on current verifier state
>     * ref_convert_owning_non_owning - convert owning reference w/
>       specified ref_obj_id to non-owning references. Setup
>       non_owning_ref_lock for each reg with that ref_obj_id and 0 out
>       its ref_obj_id
> 
>   * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
>     KF_RELEASE to indicate that the release arg reg should be converted
>     to non-owning ref
>     * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
>       the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
>       doing ref_convert_owning_non_owning on the ref first, which
>       prevents the regs from being clobbered by 0ing out their
>       ref_obj_ids. The bpf_reference_state itself is still released via
>       release_reference as a result of the KF_RELEASE flag.
>     * KF_RELEASE | KF_RELEASE_NON_OWN are added to
>       bpf_list_push_{front,back}
> 
> After these changes, linked_list's "release on unlock" logic continues
> to function as before, except for the semantic differences noted above.
> The patch immediately following this one makes minor changes to
> linked_list selftests to account for the differing behavior.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> ---
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 53d175cbaa02..cb417ffbbb84 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
>  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
>  };

[...]

>  struct bpf_reg_state {
>  	/* Ordering of fields matters.  See states_equal() */
>  	enum bpf_reg_type type;
> @@ -68,6 +84,7 @@ struct bpf_reg_state {
>  		struct {
>  			struct btf *btf;
>  			u32 btf_id;
> +			struct bpf_active_lock non_owning_ref_lock;
>  		};
>  

I think it's possible for this to be a pointer by just pointing to
struct bpf_verifier_state's active_lock. Why?

  * There can currently only be one active_lock at a time
  * non-owning refs are only valid in the critical section

So if a verifier_state has an active_lock, any non-owning ref must've been
obtained under that lock, and any non-owning ref not obtained under that
lock must have been invalidated previously. 

This will keep bpf_reg_state size down. Will give it a shot for v3,
wanted to leave it in current state for v2 so logic in this patch
is easier to reason about.

Actually, if above logic is correct, then only valid states for
non_owning_ref_lock are "empty / null" and "same as current verifier_state",
in which case this can go back to being a bool. But for non-spin_unlock
invalidation points (e.g. rbtree_remove), we may want to keep additional
info around to avoid invalidating everything, which would require
re-introducing a non_owning_ref identity.

>  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
> @@ -223,11 +240,6 @@ struct bpf_reference_state {
>  	 * exiting a callback function.
>  	 */
>  	int callback_ref;
> -	/* Mark the reference state to release the registers sharing the same id
> -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
> -	 * safe to access inside the critical section).
> -	 */
> -	bool release_on_unlock;
>  };
>  
>  /* state of the program:
> @@ -328,21 +340,8 @@ struct bpf_verifier_state {
>  	u32 branches;
>  	u32 insn_idx;
>  	u32 curframe;
> -	/* For every reg representing a map value or allocated object pointer,
> -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
> -	 * context and conside them to not alias each other for the purposes of
> -	 * tracking lock state.
> -	 */
> -	struct {
> -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> -		 * there's no active lock held, and other fields have no
> -		 * meaning. If non-NULL, it indicates that a lock is held and
> -		 * id member has the reg->id of the register which can be >= 0.
> -		 */
> -		void *ptr;
> -		/* This will be reg->id */
> -		u32 id;
> -	} active_lock;
> +
> +	struct bpf_active_lock active_lock;
>  	bool speculative;
>  	bool active_rcu_lock;

[...]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 11/13] libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj type
  2022-12-17  8:25 ` [PATCH v2 bpf-next 11/13] libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj type Dave Marchevsky
@ 2022-12-22 18:50   ` Andrii Nakryiko
  0 siblings, 0 replies; 37+ messages in thread
From: Andrii Nakryiko @ 2022-12-22 18:50 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:25 AM Dave Marchevsky <davemarchevsky@fb.com> wrote:
>
> If a BPF program defines a struct or union type which has a field type
> that the verifier considers special - spin_lock, graph datastructure
> heads and nodes - the verifier needs to be able to find fields of that
> type using BTF.
>
> For such a program, BTF is required, so modify kernel_needs_btf helper
> to ensure that correct "BTF is mandatory" error message is emitted.
>
> The newly-added btf_has_alloc_obj_type looks for BTF_KIND_STRUCTs with a
> name corresponding to a special type. If any such struct is found it is
> assumed that some variable is using it, and therefore that successful
> BTF load is necessary.
>
> Also add a kernel_needs_btf check to bpf_object__create_map where it was
> previously missing. When this function calls bpf_map_create, kernel may
> reject map creation due to mismatched graph owner and ownee
> types (e.g. a struct bpf_list_head with __contains tag pointing to
> bpf_rbtree_node field). In such a scenario - or any other where BTF is
> necessary for verification - bpf_map_create should not be retried
> without BTF.
>
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> ---
>  tools/lib/bpf/libbpf.c | 50 ++++++++++++++++++++++++++++++++----------
>  1 file changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 2a82f49ce16f..56a905b502c9 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -998,6 +998,31 @@ find_struct_ops_kern_types(const struct btf *btf, const char *tname,
>         return 0;
>  }
>
> +/* Should match alloc_obj_fields in kernel/bpf/btf.c
> + */

nit: keep comment on a single line?

> +static const char *alloc_obj_fields[] = {
> +       "bpf_spin_lock",
> +       "bpf_list_head",
> +       "bpf_list_node",
> +       "bpf_rb_root",
> +       "bpf_rb_node",
> +};
> +
> +static bool
> +btf_has_alloc_obj_type(const struct btf *btf)

I find "alloc_obj_type" naming completely unhelpful, tbh. Let's use
something more generic and unassuming as "special_btf_type" or
something along those lines?

> +{
> +       const char *tname;
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(alloc_obj_fields); i++) {
> +               tname = alloc_obj_fields[i];
> +               if (btf__find_by_name_kind(btf, tname, BTF_KIND_STRUCT) > 0)

this will do linear search over entire program's BTF for each
alloc_obj_fields element. Given alloc_obj_fields is supposed to be a
small array, I think it's better to do single linear pass over prog
BTF and for each found STRUCT check if its name matches
alloc_obj_fields.

Having said that, it feels like the better logic would be to check
that any map value's BTF (including global var ARRAYs) have a field of
one of those special types. Just searching for any STRUCT type with
one of those names feels off.

> +                       return true;
> +       }
> +
> +       return false;
> +}
> +
>  static bool bpf_map__is_struct_ops(const struct bpf_map *map)
>  {
>         return map->def.type == BPF_MAP_TYPE_STRUCT_OPS;
> @@ -2794,7 +2819,8 @@ static bool libbpf_needs_btf(const struct bpf_object *obj)
>
>  static bool kernel_needs_btf(const struct bpf_object *obj)
>  {
> -       return obj->efile.st_ops_shndx >= 0;
> +       return obj->efile.st_ops_shndx >= 0 ||
> +               (obj->btf && btf_has_alloc_obj_type(obj->btf));
>  }
>
>  static int bpf_object__init_btf(struct bpf_object *obj,
> @@ -5103,16 +5129,18 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
>
>                 err = -errno;
>                 cp = libbpf_strerror_r(err, errmsg, sizeof(errmsg));
> -               pr_warn("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
> -                       map->name, cp, err);
> -               create_attr.btf_fd = 0;
> -               create_attr.btf_key_type_id = 0;
> -               create_attr.btf_value_type_id = 0;
> -               map->btf_key_type_id = 0;
> -               map->btf_value_type_id = 0;
> -               map->fd = bpf_map_create(def->type, map_name,
> -                                        def->key_size, def->value_size,
> -                                        def->max_entries, &create_attr);
> +               pr_warn("Error in bpf_create_map_xattr(%s):%s(%d).\n", map->name, cp, err);
> +               if (!kernel_needs_btf(obj)) {

see above about check whether a map's value BTF itself is using any of
the special type. I think this decision should be made based on
particular map's need for BTF, not based on kernel_needs_btf().

I think it would be better to have an if/else with different
pr_warn()s. Both should report that initial bpf_map_create() (btw,
gotta update the message now, missed that) failed with error, but then
in one case say that we are retrying without BTF, and in another
explain that we are not because map requires kernel to see its BTF.
WDYT?

> +                       pr_warn("Retrying bpf_map_create_xattr(%s) without BTF.\n", map->name);
> +                       create_attr.btf_fd = 0;
> +                       create_attr.btf_key_type_id = 0;
> +                       create_attr.btf_value_type_id = 0;
> +                       map->btf_key_type_id = 0;
> +                       map->btf_value_type_id = 0;
> +                       map->fd = bpf_map_create(def->type, map_name,
> +                                                def->key_size, def->value_size,
> +                                                def->max_entries, &create_attr);
> +               }
>         }
>
>         err = map->fd < 0 ? -errno : 0;
> --
> 2.30.2
>

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
  2022-12-17  9:21   ` Dave Marchevsky
@ 2022-12-23 10:51   ` Dan Carpenter
  2022-12-28 23:46   ` David Vernet
  2022-12-29  3:56   ` Alexei Starovoitov
  3 siblings, 0 replies; 37+ messages in thread
From: Dan Carpenter @ 2022-12-23 10:51 UTC (permalink / raw)
  To: oe-kbuild, Dave Marchevsky, bpf
  Cc: lkp, oe-kbuild-all, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo,
	Dave Marchevsky

Hi Dave,

url:    https://github.com/intel-lab-lkp/linux/commits/Dave-Marchevsky/BPF-rbtree-next-gen-datastructure/20221217-162646
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link:    https://lore.kernel.org/r/20221217082506.1570898-3-davemarchevsky%40fb.com
patch subject: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
config: x86_64-randconfig-m001
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>

smatch warnings:
kernel/bpf/verifier.c:6275 reg_find_field_offset() warn: variable dereferenced before check 'reg' (see line 6274)

vim +/reg +6275 kernel/bpf/verifier.c

4ed17b8d6842ba Dave Marchevsky 2022-12-17  6268  static struct btf_field *
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6269  reg_find_field_offset(const struct bpf_reg_state *reg, s32 off, u32 fields)
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6270  {
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6271  	struct btf_field *field;
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6272  	struct btf_record *rec;
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6273  
4ed17b8d6842ba Dave Marchevsky 2022-12-17 @6274  	rec = reg_btf_record(reg);
4ed17b8d6842ba Dave Marchevsky 2022-12-17 @6275  	if (!reg)

Is this supposed to test rec instead of reg?

4ed17b8d6842ba Dave Marchevsky 2022-12-17  6276  		return NULL;
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6277  
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6278  	field = btf_record_find(rec, off, fields);
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6279  	if (!field)
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6280  		return NULL;
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6281  
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6282  	return field;
4ed17b8d6842ba Dave Marchevsky 2022-12-17  6283  }

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs
  2022-12-17  8:25 ` [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs Dave Marchevsky
@ 2022-12-28 21:26   ` David Vernet
  2023-01-18  2:16     ` Dave Marchevsky
  0 siblings, 1 reply; 37+ messages in thread
From: David Vernet @ 2022-12-28 21:26 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:25:06AM -0800, Dave Marchevsky wrote:
> It is difficult to intuit the semantics of owning and non-owning
> references from verifier code. In order to keep the high-level details
> from being lost in the mailing list, this patch adds documentation
> explaining semantics and details.
> 
> The target audience of doc added in this patch is folks working on BPF
> internals, as there's focus on "what should the verifier do here". Via
> reorganization or copy-and-paste, much of the content can probably be
> repurposed for BPF program writer audience as well.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>

Hey Dave,

Thanks for writing this up. I left a few comments and suggestions as a
first pass. Feel free to push back on any of them.

> ---
>  Documentation/bpf/graph_ds_impl.rst | 208 ++++++++++++++++++++++++++++
>  Documentation/bpf/other.rst         |   3 +-
>  2 files changed, 210 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/bpf/graph_ds_impl.rst
> 
> diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
> new file mode 100644
> index 000000000000..f92cbd223dc3
> --- /dev/null
> +++ b/Documentation/bpf/graph_ds_impl.rst
> @@ -0,0 +1,208 @@
> +=========================
> +BPF Graph Data Structures
> +=========================
> +
> +This document describes implementation details of new-style "graph" data
> +structures (linked_list, rbtree), with particular focus on verifier

s/with particular/with a particular

> +implementation of semantics particular to those data structures.

s/particular/specific

Just because we already use the word "particular" in the sentence?

In general this sentence feels a bit difficult to parse. Wdyt about
this?

...with a particular focus on how the verifier ensures that they are
properly and safely used by BPF programs.

> +
> +Note that the intent of this document is to describe the current state of
> +these graph data structures, **no guarantees** of stability for either

I think we can end the sentence in the middle here.

...these graph data structures. **No guarantees**...

Should we also add a sentence or two here about the intended audience
(people working on the verifier or readers who are interested in
learning more about BPF internals)?

> +semantics or APIs are made or implied here.
> +
> +.. contents::
> +    :local:
> +    :depth: 2
> +
> +Introduction
> +------------
> +
> +The BPF map API has historically been the main way to expose data structures
> +of various types for use within BPF programs. Some data structures fit naturally
> +with the map API (HASH, ARRAY), others less so. Consequentially, programs

Would you mind please adding some details on why some data structures
don't fit naturally into the existing map APIs? I feel like that's kind
of the main focus of the article, so it would probably help to give some
high-level context up front.

> +interacting with the latter group of data structures can be hard to parse
> +for kernel programmers without previous BPF experience.

I'm not sure I quite follow how this latter point about data structures
being hard to parse is derived from the point about how some data
structures don't fit naturally with the map APIs. Maybe we should say
something like:

..., others less so. Given that the API surface and behavioral semantics
are fundmentally different between these two classes of BPF data
structures, kernel programmers who are used to interacting with map-type
data structures may find these graph-type data structures to be
confusing or unfamiliar.

Wdyt?

> +
> +Luckily, some restrictions which necessitated the use of BPF map semantics are
> +no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
> +BPF allocator, it is now possible to implement BPF data structures whose API
> +and semantics more closely match those exposed to the rest of the kernel.

Suggestion, I'd consider explicitly contrasting the map-type
implementation here with the graph-type implementation. What do you
think of something like this instead of the above paragraph:

BPF map-type data structures are defined as part of the UAPI in ``enum
bpf_map_type``, and are accessed and manipulated using BPF
:doc:`helpers`. The behaviors, backing memory, and implementations of
these map-type data structures are entirely encapsulated from BPF
programs, and mostly encapsulated from the verifier, by the helper
functions. The logic in the verifier for ensuring that map-type data
structures are correctly used therefore essentially amounts to
statically verifying that the helper functions that manipulate and
access the data structure are called correctly by the program, as
defined in the helper prototypes. The verifier then relies on the helper
to properly manipulate the backing data structure with its validated
arguments.

BPF graph-type data structures, on the other hand, leverage more modern
features such as :doc:`kfuncs`, kptrs, and the any-context BPF
allocator. They allow BPF programs to manipulate the data structures
directly using APIs and semantics which more closely match those exposed
to code in the main kernel, with the verifier's job now being to ensure
that the programs are properly manipulating the data structures, rather
than relying on helper functions to properly manipulate the data
structures in the main kernel.

> +
> +Two such data structures - linked_list and rbtree - have many verification
> +details in common. Because both have "root"s ("head" for linked_list) and
> +"node"s, the verifier code and this document refer to common functionality
> +as "graph_api", "graph_root", "graph_node", etc.



> +
> +Unless otherwise stated, examples and semantics below apply to both graph data
> +structures.
> +
> +Non-owning references
> +---------------------
> +
> +**Motivation**
> +
> +Consider the following BPF code:
> +
> +.. code-block:: c

You need an extra newline here or the docs build will complain:

bpf-next/Documentation/bpf/graph_ds_impl.rst:46: ERROR: Error in "code-block" directive:
maximum 1 argument(s) allowed, 9 supplied.

.. code-block:: c
        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */

        bpf_spin_lock(&lock);

        bpf_rbtree_add(&tree, n); /* AFTER */

        bpf_spin_unlock(&lock);

> +        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
> +
> +        bpf_spin_lock(&lock);
> +
> +        bpf_rbtree_add(&tree, n); /* AFTER */
> +
> +        bpf_spin_unlock(&lock);

Also need a newline here or sphinx will get confused and think the
vertical line is part of the code block.

> +----
> +
> +From the verifier's perspective, after bpf_obj_new ``n`` has type
> +``PTR_TO_BTF_ID | MEM_ALLOC`` with btf_id of ``struct node_data`` and a
> +nonzero ``ref_obj_id``. Because it holds ``n``, the program has ownership

I had to read this first sentence a few times to parse it, maybe due to
a missing comma between "after bpf_obj_new" and "``n`` has type...".
What do you think about this wording?

From the verifier's perspective, the pointer ``n`` returned from
``bpf_obj_new`` has type ``PTR_TO_BTF_ID | MEM_ALLOC``, with a `btf_id`
of ``struct node_data``, and a nonzero ``ref_obj_id``.

> +of the pointee's lifetime (object pointed to by ``n``). The BPF program must

Should we move (object pointed to by ``n``) to be directly after
"pointee's" / before "lifetime"? Otherwise it reads kind of odd given
that "lifetime" is really the indirect object in the sentence.

> +pass off ownership before exiting - either via ``bpf_obj_drop``, which free's

s/free's/frees

> +the object, or by adding it to ``tree`` with ``bpf_rbtree_add``.
> +
> +(``BEFORE`` and ``AFTER`` comments in the example denote beginning of "before
> +ownership is passed" and "after ownership is passed")

Should we use something like ACQUIRED / PASSED / RELEASED instead of
BEFORE / AFTER?

> +
> +What should the verifier do with ``n`` after ownership is passed off? If the
> +object was free'd with ``bpf_obj_drop`` the answer is obvious: the verifier

s/free'd/freed

> +should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as
> +the object is no longer valid. The underlying memory may have been reused for
> +some other allocation, unmapped, etc.
> +
> +When ownership is passed to ``tree`` via ``bpf_rbtree_add`` the answer is less
> +obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
> +but that would result in programs with useful, common coding patterns being
> +rejected, e.g.:
> +
> +.. code-block:: c

Same here (newline)

> +        int x;
> +        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
> +
> +        bpf_spin_lock(&lock);
> +
> +        bpf_rbtree_add(&tree, n); /* AFTER */
> +        x = n->data;
> +        n->data = 42;
> +
> +        bpf_spin_unlock(&lock);

Same here (newline)

> +----
> +
> +Both the read from and write to ``n->data`` would be rejected. The verifier
> +can do better, though, by taking advantage of two details:
> +
> +  * Graph data structure APIs can only be used when the ``bpf_spin_lock``
> +    associated with the graph root is held

I'd consider giving a bit more background information on this somewhere
above. This is the first time we've mentioned anything about a lock, so
it might be worth it to give some context on how these graph-type maps
are defined and initialized.

I realize we could be approaching "useful even to people who aren't
working on the verifier" territory if we go into too much detail, but I
also think it's important to give backround context on this stuff
regardless of the intended audience in order for the documentation to
really be useful.

> +  * Both graph data structures have pointer stability

You also need a newline between nested list entries or sphinx will get
confused. My suggestion would be to just always have a newline between
list entries (applies elsewhere in the file as well).

> +    * Because graph nodes are allocated with ``bpf_obj_new`` and
> +      adding / removing from the root involves fiddling with the
> +      ``bpf_{list,rb}_node`` field of the node struct, a graph node will
> +      remain at the same address after either operation.
> +
> +Because the associated ``bpf_spin_lock`` must be held by any program adding
> +or removing, if we're in the critical section bounded by that lock, we know
> +that no other program can add or remove until the end of the critical section.
> +This combined with pointer stability means that, until the critical section
> +ends, we can safely access the graph node through ``n`` even after it was used
> +to pass ownership.
> +
> +The verifier considers such a reference a *non-owning reference*. The ref
> +returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
> +Both terms currently only have meaning in the context of graph nodes and API.
> +
> +**Details**
> +
> +Let's enumerate the properties of both types of references.
> +
> +*owning reference*
> +
> +  * This reference controls the lifetime of the pointee
> +  * Ownership of pointee must be 'released' by passing it to some graph API
> +    kfunc, or via ``bpf_obj_drop``, which free's the pointee

s/free's/frees. "Frees" is a verb, "free's" is a possessive.

> +    * If not released before program ends, verifier considers program invalid
> +  * Access to the pointee's memory will not page fault
> +
> +*non-owning reference*
> +
> +  * This reference does not own the pointee
> +    * It cannot be used to add the graph node to a graph root, nor free via
> +      ``bpf_obj_drop``
> +  * No explicit control of lifetime, but can infer valid lifetime based on
> +    non-owning ref existence (see explanation below)
> +  * Access to the pointee's memory will not page fault

I'd consider defining references, or at least giving some high-level
description of how they work, somewhere a bit earlier in the page. The
"Non-owning references" section kind of just jumps right into examples
of what the verifier allows without describing the concept at a higher
level, so readers will have a difficult time applying what they're
reading to the examples being provided.

> +
> +From verifier's perspective non-owning references can only exist
> +between spin_lock and spin_unlock. Why? After spin_unlock another program
> +can do arbitrary operations on the data structure like removing and free-ing

s/free-ing/freeing

> +via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,

s/remove'd/removed

I'll stop pointing these out for now, they apply throughout the page.

> +free'd, and reused via bpf_obj_new would point to an entirely different thing.
> +Or the memory could go away.
> +
> +To prevent this logic violation all non-owning references are invalidated by
> +verifier after critical section ends. This is necessary to ensure "will

- s/by verifier/by the verifier
- s/after critical section/after a critical section
- s/to ensure "will not"/to ensure a "will not"


> +not page fault" property of non-owning reference. So if verifier hasn't

- s/of non-owning/of the non-owning
- s/So if verifier/So if the verifier

> +invalidated a non-owning ref, accessing it will not page fault.
> +
> +Currently ``bpf_obj_drop`` is not allowed in the critical section, so
> +if there's a valid non-owning ref, we must be in critical section, and can

s/in critical section/in a critical section

> +conclude that the ref's memory hasn't been dropped-and-free'd or dropped-
> +and-reused.

If you split the line like this, it will render as "dropped-and- reused".

> +
> +Any reference to a node that is in a rbtree _must_ be non-owning, since

s/a rbtree/an rbtree

> +the tree has control of pointee lifetime. Similarly, any ref to a node

s/of pointee lifetime/of the pointee's lifetime

> +that isn't in rbtree _must_ be owning. This results in a nice property:

s/in rbtree/in an rbtree

> +graph API add / remove implementations don't need to check if a node
> +has already been added (or already removed), as the verifier type system
> +prevents such a state from being valid.

I feel like "verifier type system" isn't quite accurate here, though I
may be wrong. When I think of something like "verifier type system" I'm
more envisioning how the verifier ensures that the correct BTF IDs are
passed. In this case, it's really the BPF graph-object ownership model
that's ensuring that the state is valid, right?

> +
> +However, pointer aliasing poses an issue for the above "nice property".
> +Consider the following example:
> +
> +.. code-block:: c

Same here (newline)

> +        struct node_data *n, *m, *o, *p;
> +        n = bpf_obj_new(typeof(*n));     /* 1 */
> +
> +        bpf_spin_lock(&lock);
> +
> +        bpf_rbtree_add(&tree, n);        /* 2 */
> +        m = bpf_rbtree_first(&tree);     /* 3 */
> +
> +        o = bpf_rbtree_remove(&tree, n); /* 4 */
> +        p = bpf_rbtree_remove(&tree, m); /* 5 */
> +
> +        bpf_spin_unlock(&lock);
> +
> +        bpf_obj_drop(o);
> +        bpf_obj_drop(p); /* 6 */

Same here (newline)

> +----
> +
> +Assume tree is empty before this program runs. If we track verifier state

s/Assume tree,/Assume the tree

> +changes here using numbers in above comments:
> +
> +  1) n is an owning reference
> +  2) n is a non-owning reference, it's been added to the tree
> +  3) n and m are non-owning references, they both point to the same node
> +  4) o is an owning reference, n and m non-owning, all point to same node
> +  5) o and p are owning, n and m non-owning, all point to the same node
> +  6) a double-free has occurred, since o and p point to same node and o was
> +     free'd in previous statement
> +
> +States 4 and 5 violate our "nice property", as there are non-owning refs to
> +a node which is not in a rbtree. Statement 5 will try to remove a node which
> +has already been removed as a result of this violation. State 6 is a dangerous
> +double-free.
> +
> +At a minimum we should prevent state 6 from being possible. If we can't also
> +prevent state 5 then we must abandon our "nice property" and check whether a
> +node has already been removed at runtime.
> +
> +We prevent both by generalizing the "invalidate non-owning references" behavior
> +of ``bpf_spin_unlock`` and doing similar invalidation after
> +``bpf_rbtree_remove``. The logic here being that any graph API kfunc which:
> +
> +  * takes an arbitrary node argument
> +  * removes it from the datastructure
> +  * returns an owning reference to the removed node
> +
> +May result in a state where some other non-owning reference points to the same
> +node. So ``remove``-type kfuncs must be considered a non-owning reference
> +invalidation point as well.

Could you please also add the new kfunc flags that signal this to
Documentation/bpf/kfuncs.rst?

> diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst
> index 3d61963403b4..7e6b12018802 100644
> --- a/Documentation/bpf/other.rst
> +++ b/Documentation/bpf/other.rst
> @@ -6,4 +6,5 @@ Other
>     :maxdepth: 1
>  
>     ringbuf
> -   llvm_reloc
> \ No newline at end of file
> +   llvm_reloc
> +   graph_ds_impl
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
  2022-12-17  9:21   ` Dave Marchevsky
  2022-12-23 10:51   ` Dan Carpenter
@ 2022-12-28 23:46   ` David Vernet
  2022-12-29 15:39     ` David Vernet
  2022-12-29  3:56   ` Alexei Starovoitov
  3 siblings, 1 reply; 37+ messages in thread
From: David Vernet @ 2022-12-28 23:46 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:24:55AM -0800, Dave Marchevsky wrote:
> This patch introduces non-owning reference semantics to the verifier,
> specifically linked_list API kfunc handling. release_on_unlock logic for
> refs is refactored - with small functional changes - to implement these
> semantics, and bpf_list_push_{front,back} are migrated to use them.
> 
> When a list node is pushed to a list, the program still has a pointer to
> the node:
> 
>   n = bpf_obj_new(typeof(*n));
> 
>   bpf_spin_lock(&l);
>   bpf_list_push_back(&l, n);
>   /* n still points to the just-added node */
>   bpf_spin_unlock(&l);
> 
> What the verifier considers n to be after the push, and thus what can be
> done with n, are changed by this patch.
> 
> Common properties both before/after this patch:
>   * After push, n is only a valid reference to the node until end of
>     critical section
>   * After push, n cannot be pushed to any list
>   * After push, the program can read the node's fields using n
> 
> Before:
>   * After push, n retains the ref_obj_id which it received on
>     bpf_obj_new, but the associated bpf_reference_state's
>     release_on_unlock field is set to true
>     * release_on_unlock field and associated logic is used to implement
>       "n is only a valid ref until end of critical section"
>   * After push, n cannot be written to, the node must be removed from
>     the list before writing to its fields
>   * After push, n is marked PTR_UNTRUSTED
> 
> After:
>   * After push, n's ref is released and ref_obj_id set to 0. The
>     bpf_reg_state's non_owning_ref_lock struct is populated with the
>     currently active lock
>     * non_owning_ref_lock and logic is used to implement "n is only a
>       valid ref until end of critical section"
>   * n can be written to (except for special fields e.g. bpf_list_node,
>     timer, ...)
>   * No special type flag is added to n after push
> 
> Summary of specific implementation changes to achieve the above:
> 
>   * release_on_unlock field, ref_set_release_on_unlock helper, and logic
>     to "release on unlock" based on that field are removed
> 
>   * The anonymous active_lock struct used by bpf_verifier_state is
>     pulled out into a named struct bpf_active_lock.
> 
>   * A non_owning_ref_lock field of type bpf_active_lock is added to
>     bpf_reg_state's PTR_TO_BTF_ID union
> 
>   * Helpers are added to use non_owning_ref_lock to implement non-owning
>     ref semantics as described above
>     * invalidate_non_owning_refs - helper to clobber all non-owning refs
>       matching a particular bpf_active_lock identity. Replaces
>       release_on_unlock logic in process_spin_lock.
>     * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
>       on current verifier state
>     * ref_convert_owning_non_owning - convert owning reference w/
>       specified ref_obj_id to non-owning references. Setup
>       non_owning_ref_lock for each reg with that ref_obj_id and 0 out
>       its ref_obj_id
> 
>   * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
>     KF_RELEASE to indicate that the release arg reg should be converted
>     to non-owning ref
>     * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
>       the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
>       doing ref_convert_owning_non_owning on the ref first, which
>       prevents the regs from being clobbered by 0ing out their
>       ref_obj_ids. The bpf_reference_state itself is still released via
>       release_reference as a result of the KF_RELEASE flag.
>     * KF_RELEASE | KF_RELEASE_NON_OWN are added to
>       bpf_list_push_{front,back}
> 
> After these changes, linked_list's "release on unlock" logic continues
> to function as before, except for the semantic differences noted above.
> The patch immediately following this one makes minor changes to
> linked_list selftests to account for the differing behavior.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>

Hey Dave,

I'm sorry to be chiming in a bit late in the game here, but I only
finally had the time to fully review some of this stuff during the
holiday-lull, and I have a few questions / concerns about the whole
owning vs. non-owning refcount approach we're taking here.

> ---
>  include/linux/bpf.h          |   1 +
>  include/linux/bpf_verifier.h |  39 ++++-----
>  include/linux/btf.h          |  17 ++--
>  kernel/bpf/helpers.c         |   4 +-
>  kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
>  5 files changed, 146 insertions(+), 79 deletions(-)
> 
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 3de24cfb7a3d..f71571bf6adc 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -180,6 +180,7 @@ enum btf_field_type {
>  	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
>  	BPF_LIST_HEAD  = (1 << 4),
>  	BPF_LIST_NODE  = (1 << 5),
> +	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
>  };
>  
>  struct btf_field_kptr {
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 53d175cbaa02..cb417ffbbb84 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
>  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
>  };
>  
> +/* For every reg representing a map value or allocated object pointer,
> + * we consider the tuple of (ptr, id) for them to be unique in verifier
> + * context and conside them to not alias each other for the purposes of
> + * tracking lock state.
> + */
> +struct bpf_active_lock {
> +	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> +	 * there's no active lock held, and other fields have no
> +	 * meaning. If non-NULL, it indicates that a lock is held and
> +	 * id member has the reg->id of the register which can be >= 0.
> +	 */
> +	void *ptr;
> +	/* This will be reg->id */
> +	u32 id;
> +};
> +
>  struct bpf_reg_state {
>  	/* Ordering of fields matters.  See states_equal() */
>  	enum bpf_reg_type type;
> @@ -68,6 +84,7 @@ struct bpf_reg_state {
>  		struct {
>  			struct btf *btf;
>  			u32 btf_id;
> +			struct bpf_active_lock non_owning_ref_lock;
>  		};
>  
>  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
> @@ -223,11 +240,6 @@ struct bpf_reference_state {
>  	 * exiting a callback function.
>  	 */
>  	int callback_ref;
> -	/* Mark the reference state to release the registers sharing the same id
> -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
> -	 * safe to access inside the critical section).
> -	 */
> -	bool release_on_unlock;
>  };
>  
>  /* state of the program:
> @@ -328,21 +340,8 @@ struct bpf_verifier_state {
>  	u32 branches;
>  	u32 insn_idx;
>  	u32 curframe;
> -	/* For every reg representing a map value or allocated object pointer,
> -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
> -	 * context and conside them to not alias each other for the purposes of
> -	 * tracking lock state.
> -	 */
> -	struct {
> -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> -		 * there's no active lock held, and other fields have no
> -		 * meaning. If non-NULL, it indicates that a lock is held and
> -		 * id member has the reg->id of the register which can be >= 0.
> -		 */
> -		void *ptr;
> -		/* This will be reg->id */
> -		u32 id;
> -	} active_lock;
> +
> +	struct bpf_active_lock active_lock;
>  	bool speculative;
>  	bool active_rcu_lock;
>  
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 5f628f323442..8aee3f7f4248 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -15,10 +15,10 @@
>  #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
>  
>  /* These need to be macros, as the expressions are used in assembler input */
> -#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
> -#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
> -#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
> -#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
> +#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
> +#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
> +#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
> +#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
>  /* Trusted arguments are those which are guaranteed to be valid when passed to
>   * the kfunc. It is used to enforce that pointers obtained from either acquire
>   * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
> @@ -67,10 +67,11 @@
>   *	return 0;
>   * }
>   */
> -#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
> -#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
> -#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
> -#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
> +#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
> +#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
> +#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
> +#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
> +#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */

It would be nice if we could come up with new kfunc flag names that
don't have 'RELEASE' in it. As is this is arguably a bit of a leaky
abstraction given that kfunc authors now have to understand a notion of
"releasing", "releasing but keeping a non-owning ref", and "releasing
but it must be a non-owning reference". I know that in [0] you mention
that the notions of owning and non-owning references are entirely
relegated to graph-type maps, but I disagree. More below.

[0]: https://lore.kernel.org/all/20221217082506.1570898-14-davemarchevsky@fb.com/

In general, IMO this muddies the existing, crystal-clear semantics of
BPF object ownership and refcounting. Usually a "weak" or "non-owning"
reference is a shadow of a strong reference, and "using" the weak
reference requires attempting (because it could fail) to temporarily
promote it to a strong reference. If successful, the object's existence
is guaranteed until the weak pointer is demoted back to a weak pointer
and/or the promoted strong pointer is released, and it's perfectly valid
for an object's lifetime to be extended due to a promoted weak pointer
not dropping its reference until after all the other strong pointer
references have been dropped. The key point here is that a pointer's
safety is entirely dictated by whether or not the holder has or is able
to acquire a strong reference, and nothing more.

In contrast, if I understand correctly, in this proposal a "non-owning"
reference means that the object is guaranteed to be valid due to
external factors such as a lock being held on the root node of the
graph, and is used to e.g. signal whether an object has or has not yet
been added as a node to an rbtree or a list. If so, IMO these are
completely separate concepts from refcounting, and I don't think we
should intertwine it with the acquire / release semantics that we
currently use for ensuring object lifetime.

Note that weak references are usually (if not always, at least in my
experience) used to resolve circular dependencies where the reference
would always be leaked if both sides had a strong reference. I don't
think that applies here, where instead we're using "owning reference" to
mean that ownership of the object has not yet been passed to a
graph-type data structure, and "non-owning reference" to mean that the
graph now owns the strong reference, but it's still safe to reference
the object due to it being protected by some external synchronization
mechanism like a lock. There's no danger of a circular dependency here,
we just want to provide consistent API semantics.

If we want to encapsulate notions of "safe due to a lock being held on a
root node", and "pointer hasn't yet been inserted into the graph", I
think we should consider adding some entirely separate abstractions. For
example, something like PTR_GRAPH_STORED on the register type-modifier
side for signaling whether a pointer has already been stored in a graph,
and KF_GRAPH_INSERT, KF_GRAPH_REMOVE type kfunc flags for adding and
removing from graphs respectively. I don't think we'd have to add
anything at all for ensuring pointer safety from the lock being held, as
the verifier should be able to figure out that a pointer that was
inserted with KF_GRAPH_INSERT is safe to reference inside of the locked
region of the lock associated with the root node. The refcnt of the
object isn't relevant at all, it's the association of the root node with
a specific lock.

>  
>  /*
>   * Return the name of the passed struct, if exists, or halt the build if for
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index af30c6cbd65d..e041409779c3 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
>  #endif
>  BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
>  BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
> -BTF_ID_FLAGS(func, bpf_list_push_front)
> -BTF_ID_FLAGS(func, bpf_list_push_back)
> +BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
> +BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)

I don't think a helper should specify both of these flags together.
IIUC, what this is saying is something along the lines of, "Release the
reference, but rather than actually releasing it, just keep it and
convert it into a non-owning reference". IMO KF_RELEASE should always
mean, exclusively, "I'm releasing a previously-acquired strong reference
to an object", and the expectation should be that the object cannot be
referenced _at all_ afterwards, unless you happen to have another strong
reference.

IMO this is another sign that we should consider going in a different
direction for owning vs.  non-owning references. I don't think this
makes sense from an object-refcounting perspective, but I readily admit
that I could be missing a lot of important context here.

[...]

Thanks,
David

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2022-12-17  8:24 ` [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs Dave Marchevsky
@ 2022-12-29  3:24   ` Alexei Starovoitov
  2022-12-29  6:40   ` David Vernet
  1 sibling, 0 replies; 37+ messages in thread
From: Alexei Starovoitov @ 2022-12-29  3:24 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:24:54AM -0800, Dave Marchevsky wrote:
> Currently, kfuncs marked KF_RELEASE indicate that they release some
> previously-acquired arg. The verifier assumes that such a function will
> only have one arg reg w/ ref_obj_id set, and that that arg is the one to
> be released. Multiple kfunc arg regs have ref_obj_id set is considered
> an invalid state.
> 
> For helpers, RELEASE is used to tag a particular arg in the function
> proto, not the function itself. The arg with OBJ_RELEASE type tag is the
> arg that the helper will release. There can only be one such tagged arg.
> When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
> also considered an invalid state.
> 
> Later patches in this series will result in some linked_list helpers
> marked KF_RELEASE having a valid reason to take two ref_obj_id args.
> Specifically, bpf_list_push_{front,back} can push a node to a list head
> which is itself part of a list node. In such a scenario both arguments
> to these functions would have ref_obj_id > 0, thus would fail
> verification under current logic.

Well, I think this patch is unnecessary, because there is really no need
to mark lish_push as KF_RELEASE.
The verifier still has to do custom checks for both arguments:
list_node and list_head.
They are different enough. The 'generalization' via
KF_RELEASE | KF_RELEASE_NON_OWN is quite confusing.
Especially considering how register is being picked: 1st vs 2nd.
More details on this in the other reply to patch 2.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
                     ` (2 preceding siblings ...)
  2022-12-28 23:46   ` David Vernet
@ 2022-12-29  3:56   ` Alexei Starovoitov
  2022-12-29 16:54     ` David Vernet
  2023-01-17 16:07     ` Dave Marchevsky
  3 siblings, 2 replies; 37+ messages in thread
From: Alexei Starovoitov @ 2022-12-29  3:56 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:24:55AM -0800, Dave Marchevsky wrote:
> This patch introduces non-owning reference semantics to the verifier,
> specifically linked_list API kfunc handling. release_on_unlock logic for
> refs is refactored - with small functional changes - to implement these
> semantics, and bpf_list_push_{front,back} are migrated to use them.
> 
> When a list node is pushed to a list, the program still has a pointer to
> the node:
> 
>   n = bpf_obj_new(typeof(*n));
> 
>   bpf_spin_lock(&l);
>   bpf_list_push_back(&l, n);
>   /* n still points to the just-added node */
>   bpf_spin_unlock(&l);
> 
> What the verifier considers n to be after the push, and thus what can be
> done with n, are changed by this patch.
> 
> Common properties both before/after this patch:
>   * After push, n is only a valid reference to the node until end of
>     critical section
>   * After push, n cannot be pushed to any list
>   * After push, the program can read the node's fields using n

correct.

> Before:
>   * After push, n retains the ref_obj_id which it received on
>     bpf_obj_new, but the associated bpf_reference_state's
>     release_on_unlock field is set to true
>     * release_on_unlock field and associated logic is used to implement
>       "n is only a valid ref until end of critical section"
>   * After push, n cannot be written to, the node must be removed from
>     the list before writing to its fields
>   * After push, n is marked PTR_UNTRUSTED

yep

> After:
>   * After push, n's ref is released and ref_obj_id set to 0. The
>     bpf_reg_state's non_owning_ref_lock struct is populated with the
>     currently active lock
>     * non_owning_ref_lock and logic is used to implement "n is only a
>       valid ref until end of critical section"
>   * n can be written to (except for special fields e.g. bpf_list_node,
>     timer, ...)
>   * No special type flag is added to n after push

yep.
Great summary.

> Summary of specific implementation changes to achieve the above:
> 
>   * release_on_unlock field, ref_set_release_on_unlock helper, and logic
>     to "release on unlock" based on that field are removed

+1 

>   * The anonymous active_lock struct used by bpf_verifier_state is
>     pulled out into a named struct bpf_active_lock.
...
>   * A non_owning_ref_lock field of type bpf_active_lock is added to
>     bpf_reg_state's PTR_TO_BTF_ID union

not great. see below.

>   * Helpers are added to use non_owning_ref_lock to implement non-owning
>     ref semantics as described above
>     * invalidate_non_owning_refs - helper to clobber all non-owning refs
>       matching a particular bpf_active_lock identity. Replaces
>       release_on_unlock logic in process_spin_lock.

+1

>     * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
>       on current verifier state

+1

>     * ref_convert_owning_non_owning - convert owning reference w/
>       specified ref_obj_id to non-owning references. Setup
>       non_owning_ref_lock for each reg with that ref_obj_id and 0 out
>       its ref_obj_id

+1

>   * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
>     KF_RELEASE to indicate that the release arg reg should be converted
>     to non-owning ref
>     * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
>       the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
>       doing ref_convert_owning_non_owning on the ref first, which
>       prevents the regs from being clobbered by 0ing out their
>       ref_obj_ids. The bpf_reference_state itself is still released via
>       release_reference as a result of the KF_RELEASE flag.
>     * KF_RELEASE | KF_RELEASE_NON_OWN are added to
>       bpf_list_push_{front,back}

And this bit is confusing and not generalizable.
As David noticed in his reply KF_RELEASE_NON_OWN is not a great name.
It's hard to come up with a good name and it won't be generic anyway.
The ref_convert_owning_non_owning has to be applied to a specific arg.
The function itself is not KF_RELEASE in the current definition of it.
The combination of KF_RELEASE|KF_RELEASE_NON_OWN is something new
that should have been generic, but doesn't really work this way.
In the next patches rbtree_root/node still has to have all the custom
logic.
KF_RELEASE_NON_OWN by itself is a nonsensical flag.
Only combination of KF_RELEASE|KF_RELEASE_NON_OWN sort-of kinda makes
sense, but still hard to understand what releases what.
More below.

> After these changes, linked_list's "release on unlock" logic continues
> to function as before, except for the semantic differences noted above.
> The patch immediately following this one makes minor changes to
> linked_list selftests to account for the differing behavior.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> ---
>  include/linux/bpf.h          |   1 +
>  include/linux/bpf_verifier.h |  39 ++++-----
>  include/linux/btf.h          |  17 ++--
>  kernel/bpf/helpers.c         |   4 +-
>  kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
>  5 files changed, 146 insertions(+), 79 deletions(-)
> 
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 3de24cfb7a3d..f71571bf6adc 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -180,6 +180,7 @@ enum btf_field_type {
>  	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
>  	BPF_LIST_HEAD  = (1 << 4),
>  	BPF_LIST_NODE  = (1 << 5),
> +	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
>  };
>  
>  struct btf_field_kptr {
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 53d175cbaa02..cb417ffbbb84 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
>  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
>  };
>  
> +/* For every reg representing a map value or allocated object pointer,
> + * we consider the tuple of (ptr, id) for them to be unique in verifier
> + * context and conside them to not alias each other for the purposes of
> + * tracking lock state.
> + */
> +struct bpf_active_lock {
> +	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> +	 * there's no active lock held, and other fields have no
> +	 * meaning. If non-NULL, it indicates that a lock is held and
> +	 * id member has the reg->id of the register which can be >= 0.
> +	 */
> +	void *ptr;
> +	/* This will be reg->id */
> +	u32 id;
> +};
> +
>  struct bpf_reg_state {
>  	/* Ordering of fields matters.  See states_equal() */
>  	enum bpf_reg_type type;
> @@ -68,6 +84,7 @@ struct bpf_reg_state {
>  		struct {
>  			struct btf *btf;
>  			u32 btf_id;
> +			struct bpf_active_lock non_owning_ref_lock;

In your other email you argue that pointer should be enough.
I suspect that won't be correct.
See fixes that Andrii did in states_equal() and regsafe().
In particular:
        if (!!old->active_lock.id != !!cur->active_lock.id)
                return false;

        if (old->active_lock.id &&
            !check_ids(old->active_lock.id, cur->active_lock.id, env->idmap_scratch))
                return false;

We have to do the comparison of this new ID via idmap as well.

I think introduction of struct bpf_active_lock  and addition of it
to bpf_reg_state is overkill.
Here we can add 'u32 non_own_ref_obj_id;' only and compare it via idmap in regsafe().
I'm guessing you didn't like my 'active_lock_id' suggestion. Fine.
non_own_ref_obj_id would match existing ref_obj_id at least.

>  		};
>  
>  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
> @@ -223,11 +240,6 @@ struct bpf_reference_state {
>  	 * exiting a callback function.
>  	 */
>  	int callback_ref;
> -	/* Mark the reference state to release the registers sharing the same id
> -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
> -	 * safe to access inside the critical section).
> -	 */
> -	bool release_on_unlock;
>  };
>  
>  /* state of the program:
> @@ -328,21 +340,8 @@ struct bpf_verifier_state {
>  	u32 branches;
>  	u32 insn_idx;
>  	u32 curframe;
> -	/* For every reg representing a map value or allocated object pointer,
> -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
> -	 * context and conside them to not alias each other for the purposes of
> -	 * tracking lock state.
> -	 */
> -	struct {
> -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> -		 * there's no active lock held, and other fields have no
> -		 * meaning. If non-NULL, it indicates that a lock is held and
> -		 * id member has the reg->id of the register which can be >= 0.
> -		 */
> -		void *ptr;
> -		/* This will be reg->id */
> -		u32 id;
> -	} active_lock;

I would keep it as-is.

> +
> +	struct bpf_active_lock active_lock;
>  	bool speculative;
>  	bool active_rcu_lock;
>  
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 5f628f323442..8aee3f7f4248 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -15,10 +15,10 @@
>  #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
>  
>  /* These need to be macros, as the expressions are used in assembler input */
> -#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
> -#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
> -#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
> -#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
> +#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
> +#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
> +#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
> +#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
>  /* Trusted arguments are those which are guaranteed to be valid when passed to
>   * the kfunc. It is used to enforce that pointers obtained from either acquire
>   * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
> @@ -67,10 +67,11 @@
>   *	return 0;
>   * }
>   */
> -#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
> -#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
> -#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
> -#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
> +#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
> +#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
> +#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
> +#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
> +#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */

No need for this flag.

>  /*
>   * Return the name of the passed struct, if exists, or halt the build if for
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index af30c6cbd65d..e041409779c3 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
>  #endif
>  BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
>  BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
> -BTF_ID_FLAGS(func, bpf_list_push_front)
> -BTF_ID_FLAGS(func, bpf_list_push_back)
> +BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
> +BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)

No need for this.

>  BTF_ID_FLAGS(func, bpf_list_pop_front, KF_ACQUIRE | KF_RET_NULL)
>  BTF_ID_FLAGS(func, bpf_list_pop_back, KF_ACQUIRE | KF_RET_NULL)
>  BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 824e2242eae5..84b0660e2a76 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -190,6 +190,10 @@ struct bpf_verifier_stack_elem {
>  
>  static int acquire_reference_state(struct bpf_verifier_env *env, int insn_idx);
>  static int release_reference(struct bpf_verifier_env *env, int ref_obj_id);
> +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
> +				       struct bpf_active_lock *lock);
> +static int ref_set_non_owning_lock(struct bpf_verifier_env *env,
> +				   struct bpf_reg_state *reg);
>  
>  static bool bpf_map_ptr_poisoned(const struct bpf_insn_aux_data *aux)
>  {
> @@ -931,6 +935,9 @@ static void print_verifier_state(struct bpf_verifier_env *env,
>  				verbose_a("id=%d", reg->id);
>  			if (reg->ref_obj_id)
>  				verbose_a("ref_obj_id=%d", reg->ref_obj_id);
> +			if (reg->non_owning_ref_lock.ptr)
> +				verbose_a("non_own_id=(%p,%d)", reg->non_owning_ref_lock.ptr,
> +					  reg->non_owning_ref_lock.id);
>  			if (t != SCALAR_VALUE)
>  				verbose_a("off=%d", reg->off);
>  			if (type_is_pkt_pointer(t))
> @@ -4820,7 +4827,8 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
>  			return -EACCES;
>  		}
>  
> -		if (type_is_alloc(reg->type) && !reg->ref_obj_id) {
> +		if (type_is_alloc(reg->type) && !reg->ref_obj_id &&
> +		    !reg->non_owning_ref_lock.ptr) {
>  			verbose(env, "verifier internal error: ref_obj_id for allocated object must be non-zero\n");
>  			return -EFAULT;
>  		}
> @@ -5778,9 +5786,7 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
>  			cur->active_lock.ptr = btf;
>  		cur->active_lock.id = reg->id;
>  	} else {
> -		struct bpf_func_state *fstate = cur_func(env);
>  		void *ptr;
> -		int i;
>  
>  		if (map)
>  			ptr = map;
> @@ -5796,25 +5802,11 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
>  			verbose(env, "bpf_spin_unlock of different lock\n");
>  			return -EINVAL;
>  		}
> -		cur->active_lock.ptr = NULL;
> -		cur->active_lock.id = 0;
>  
> -		for (i = fstate->acquired_refs - 1; i >= 0; i--) {
> -			int err;
> +		invalidate_non_owning_refs(env, &cur->active_lock);

+1

> -			/* Complain on error because this reference state cannot
> -			 * be freed before this point, as bpf_spin_lock critical
> -			 * section does not allow functions that release the
> -			 * allocated object immediately.
> -			 */
> -			if (!fstate->refs[i].release_on_unlock)
> -				continue;
> -			err = release_reference(env, fstate->refs[i].id);
> -			if (err) {
> -				verbose(env, "failed to release release_on_unlock reference");
> -				return err;
> -			}
> -		}
> +		cur->active_lock.ptr = NULL;
> +		cur->active_lock.id = 0;

+1

>  	}
>  	return 0;
>  }
> @@ -6273,6 +6265,23 @@ static int check_reg_type(struct bpf_verifier_env *env, u32 regno,
>  	return 0;
>  }
>  
> +static struct btf_field *
> +reg_find_field_offset(const struct bpf_reg_state *reg, s32 off, u32 fields)
> +{
> +	struct btf_field *field;
> +	struct btf_record *rec;
> +
> +	rec = reg_btf_record(reg);
> +	if (!reg)
> +		return NULL;
> +
> +	field = btf_record_find(rec, off, fields);
> +	if (!field)
> +		return NULL;
> +
> +	return field;
> +}

Doesn't look like that this helper is really necessary.

> +
>  int check_func_arg_reg_off(struct bpf_verifier_env *env,
>  			   const struct bpf_reg_state *reg, int regno,
>  			   enum bpf_arg_type arg_type)
> @@ -6294,6 +6303,18 @@ int check_func_arg_reg_off(struct bpf_verifier_env *env,
>  		 */
>  		if (arg_type_is_dynptr(arg_type) && type == PTR_TO_STACK)
>  			return 0;
> +
> +		if (type == (PTR_TO_BTF_ID | MEM_ALLOC) && reg->off) {
> +			if (reg_find_field_offset(reg, reg->off, BPF_GRAPH_NODE_OR_ROOT))
> +				return __check_ptr_off_reg(env, reg, regno, true);
> +
> +			verbose(env, "R%d must have zero offset when passed to release func\n",
> +				regno);
> +			verbose(env, "No graph node or root found at R%d type:%s off:%d\n", regno,
> +				kernel_type_name(reg->btf, reg->btf_id), reg->off);
> +			return -EINVAL;
> +		}

This bit is only necessary if we mark push_list as KF_RELEASE.
Just don't add this mark and drop above.

> +
>  		/* Doing check_ptr_off_reg check for the offset will catch this
>  		 * because fixed_off_ok is false, but checking here allows us
>  		 * to give the user a better error message.
> @@ -7055,6 +7076,20 @@ static int release_reference(struct bpf_verifier_env *env,
>  	return 0;
>  }
>  
> +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
> +				       struct bpf_active_lock *lock)
> +{
> +	struct bpf_func_state *unused;
> +	struct bpf_reg_state *reg;
> +
> +	bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
> +		if (reg->non_owning_ref_lock.ptr &&
> +		    reg->non_owning_ref_lock.ptr == lock->ptr &&
> +		    reg->non_owning_ref_lock.id == lock->id)

I think the lock.ptr = lock->ptr comparison is unnecessary to invalidate things.
We're under active spin_lock here. All regs were checked earlier and id keeps incrementing.
So we can just do 'u32 non_own_ref_obj_id'.

> +			__mark_reg_unknown(env, reg);
> +	}));
> +}
> +
>  static void clear_caller_saved_regs(struct bpf_verifier_env *env,
>  				    struct bpf_reg_state *regs)
>  {
> @@ -8266,6 +8301,11 @@ static bool is_kfunc_release(struct bpf_kfunc_call_arg_meta *meta)
>  	return meta->kfunc_flags & KF_RELEASE;
>  }
>  
> +static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
> +{
> +	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
> +}
> +

No need.

>  static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
>  {
>  	return meta->kfunc_flags & KF_TRUSTED_ARGS;
> @@ -8651,38 +8691,55 @@ static int process_kf_arg_ptr_to_kptr(struct bpf_verifier_env *env,
>  	return 0;
>  }
>  
> -static int ref_set_release_on_unlock(struct bpf_verifier_env *env, u32 ref_obj_id)
> +static int ref_set_non_owning_lock(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
>  {
> -	struct bpf_func_state *state = cur_func(env);
> +	struct bpf_verifier_state *state = env->cur_state;
> +
> +	if (!state->active_lock.ptr) {
> +		verbose(env, "verifier internal error: ref_set_non_owning_lock w/o active lock\n");
> +		return -EFAULT;
> +	}
> +
> +	if (reg->non_owning_ref_lock.ptr) {
> +		verbose(env, "verifier internal error: non_owning_ref_lock already set\n");
> +		return -EFAULT;
> +	}
> +
> +	reg->non_owning_ref_lock.id = state->active_lock.id;
> +	reg->non_owning_ref_lock.ptr = state->active_lock.ptr;
> +	return 0;
> +}
> +
> +static int ref_convert_owning_non_owning(struct bpf_verifier_env *env, u32 ref_obj_id)
> +{
> +	struct bpf_func_state *state, *unused;
>  	struct bpf_reg_state *reg;
>  	int i;
>  
> -	/* bpf_spin_lock only allows calling list_push and list_pop, no BPF
> -	 * subprogs, no global functions. This means that the references would
> -	 * not be released inside the critical section but they may be added to
> -	 * the reference state, and the acquired_refs are never copied out for a
> -	 * different frame as BPF to BPF calls don't work in bpf_spin_lock
> -	 * critical sections.
> -	 */
> +	state = cur_func(env);
> +
>  	if (!ref_obj_id) {
> -		verbose(env, "verifier internal error: ref_obj_id is zero for release_on_unlock\n");
> +		verbose(env, "verifier internal error: ref_obj_id is zero for "
> +			     "owning -> non-owning conversion\n");
>  		return -EFAULT;
>  	}
> +
>  	for (i = 0; i < state->acquired_refs; i++) {
> -		if (state->refs[i].id == ref_obj_id) {
> -			if (state->refs[i].release_on_unlock) {
> -				verbose(env, "verifier internal error: expected false release_on_unlock");
> -				return -EFAULT;
> +		if (state->refs[i].id != ref_obj_id)
> +			continue;
> +
> +		/* Clear ref_obj_id here so release_reference doesn't clobber
> +		 * the whole reg
> +		 */
> +		bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
> +			if (reg->ref_obj_id == ref_obj_id) {
> +				reg->ref_obj_id = 0;
> +				ref_set_non_owning_lock(env, reg);

+1 except ref_set_... name doesn't quite fit. reg_set_... is more accurate, no?
and probably reg_set_non_own_ref_obj_id() ?
Or just open code it?

>  			}
> -			state->refs[i].release_on_unlock = true;
> -			/* Now mark everyone sharing same ref_obj_id as untrusted */
> -			bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
> -				if (reg->ref_obj_id == ref_obj_id)
> -					reg->type |= PTR_UNTRUSTED;
> -			}));
> -			return 0;
> -		}
> +		}));
> +		return 0;
>  	}
> +
>  	verbose(env, "verifier internal error: ref state missing for ref_obj_id\n");
>  	return -EFAULT;
>  }
> @@ -8817,7 +8874,6 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>  {
>  	const struct btf_type *et, *t;
>  	struct btf_field *field;
> -	struct btf_record *rec;
>  	u32 list_node_off;
>  
>  	if (meta->btf != btf_vmlinux ||
> @@ -8834,9 +8890,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>  		return -EINVAL;
>  	}
>  
> -	rec = reg_btf_record(reg);
>  	list_node_off = reg->off + reg->var_off.value;
> -	field = btf_record_find(rec, list_node_off, BPF_LIST_NODE);
> +	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
>  	if (!field || field->offset != list_node_off) {
>  		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
>  		return -EINVAL;
> @@ -8861,8 +8916,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>  			btf_name_by_offset(field->list_head.btf, et->name_off));
>  		return -EINVAL;
>  	}
> -	/* Set arg#1 for expiration after unlock */
> -	return ref_set_release_on_unlock(env, reg->ref_obj_id);
> +
> +	return 0;

and here we come to the main point.
Can you just call
ref_convert_owning_non_owning(env, reg->ref_obj_id) and release_reference() here?
Everything will be so much simpler, no?

>  }
>  
>  static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
> @@ -9132,11 +9187,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  			    int *insn_idx_p)
>  {
>  	const struct btf_type *t, *func, *func_proto, *ptr_type;
> +	u32 i, nargs, func_id, ptr_type_id, release_ref_obj_id;
>  	struct bpf_reg_state *regs = cur_regs(env);
>  	const char *func_name, *ptr_type_name;
>  	bool sleepable, rcu_lock, rcu_unlock;
>  	struct bpf_kfunc_call_arg_meta meta;
> -	u32 i, nargs, func_id, ptr_type_id;
>  	int err, insn_idx = *insn_idx_p;
>  	const struct btf_param *args;
>  	const struct btf_type *ret_t;
> @@ -9223,7 +9278,18 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  	 * PTR_TO_BTF_ID in bpf_kfunc_arg_meta, do the release now.
>  	 */
>  	if (meta.release_regno) {
> -		err = release_reference(env, regs[meta.release_regno].ref_obj_id);
> +		err = 0;
> +		release_ref_obj_id = regs[meta.release_regno].ref_obj_id;
> +
> +		if (is_kfunc_release_non_own(&meta))
> +			err = ref_convert_owning_non_owning(env, release_ref_obj_id);
> +		if (err) {
> +			verbose(env, "kfunc %s#%d conversion of owning ref to non-owning failed\n",
> +				func_name, func_id);
> +			return err;
> +		}
> +
> +		err = release_reference(env, release_ref_obj_id);

and this bit won't be needed.
and no need to guess in patch 1 which arg has to be released and converted to non_own.

>  		if (err) {
>  			verbose(env, "kfunc %s#%d reference has not been acquired before\n",
>  				func_name, func_id);
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 07/13] bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args
  2022-12-17  8:25 ` [PATCH v2 bpf-next 07/13] bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args Dave Marchevsky
@ 2022-12-29  4:00   ` Alexei Starovoitov
  0 siblings, 0 replies; 37+ messages in thread
From: Alexei Starovoitov @ 2022-12-29  4:00 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:25:00AM -0800, Dave Marchevsky wrote:
>  
> +static int
> +__process_kf_arg_ptr_to_graph_node(struct bpf_verifier_env *env,
> +				   struct bpf_reg_state *reg, u32 regno,
> +				   struct bpf_kfunc_call_arg_meta *meta,
> +				   enum btf_field_type head_field_type,
> +				   enum btf_field_type node_field_type,
> +				   struct btf_field **node_field)
> +{
> +	const char *node_type_name;
>  	const struct btf_type *et, *t;
>  	struct btf_field *field;
> -	u32 list_node_off;
> +	u32 node_off;
>  
> -	if (meta->btf != btf_vmlinux ||
> -	    (meta->func_id != special_kfunc_list[KF_bpf_list_push_front] &&
> -	     meta->func_id != special_kfunc_list[KF_bpf_list_push_back])) {
> -		verbose(env, "verifier internal error: bpf_list_node argument for unknown kfunc\n");
> +	if (meta->btf != btf_vmlinux) {
> +		verbose(env, "verifier internal error: unexpected btf mismatch in kfunc call\n");
>  		return -EFAULT;
>  	}
>  
> +	if (!check_kfunc_is_graph_node_api(env, node_field_type, meta->func_id))
> +		return -EFAULT;
> +
> +	node_type_name = btf_field_type_name(node_field_type);
>  	if (!tnum_is_const(reg->var_off)) {
>  		verbose(env,
> -			"R%d doesn't have constant offset. bpf_list_node has to be at the constant offset\n",
> -			regno);
> +			"R%d doesn't have constant offset. %s has to be at the constant offset\n",
> +			regno, node_type_name);
>  		return -EINVAL;
>  	}
>  
> -	list_node_off = reg->off + reg->var_off.value;
> -	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
> -	if (!field || field->offset != list_node_off) {
> -		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
> +	node_off = reg->off + reg->var_off.value;
> +	field = reg_find_field_offset(reg, node_off, node_field_type);
> +	if (!field || field->offset != node_off) {
> +		verbose(env, "%s not found at offset=%u\n", node_type_name, node_off);
>  		return -EINVAL;
>  	}
>  
> -	field = meta->arg_list_head.field;
> +	field = *node_field;
>  
>  	et = btf_type_by_id(field->graph_root.btf, field->graph_root.value_btf_id);
>  	t = btf_type_by_id(reg->btf, reg->btf_id);
>  	if (!btf_struct_ids_match(&env->log, reg->btf, reg->btf_id, 0, field->graph_root.btf,
>  				  field->graph_root.value_btf_id, true)) {
> -		verbose(env, "operation on bpf_list_head expects arg#1 bpf_list_node at offset=%d "
> +		verbose(env, "operation on %s expects arg#1 %s at offset=%d "
>  			"in struct %s, but arg is at offset=%d in struct %s\n",
> +			btf_field_type_name(head_field_type),
> +			btf_field_type_name(node_field_type),
>  			field->graph_root.node_offset,
>  			btf_name_by_offset(field->graph_root.btf, et->name_off),
> -			list_node_off, btf_name_by_offset(reg->btf, t->name_off));
> +			node_off, btf_name_by_offset(reg->btf, t->name_off));
>  		return -EINVAL;
>  	}
>  
> -	if (list_node_off != field->graph_root.node_offset) {
> -		verbose(env, "arg#1 offset=%d, but expected bpf_list_node at offset=%d in struct %s\n",
> -			list_node_off, field->graph_root.node_offset,
> +	if (node_off != field->graph_root.node_offset) {
> +		verbose(env, "arg#1 offset=%d, but expected %s at offset=%d in struct %s\n",
> +			node_off, btf_field_type_name(node_field_type),
> +			field->graph_root.node_offset,
>  			btf_name_by_offset(field->graph_root.btf, et->name_off));
>  		return -EINVAL;
>  	}
> @@ -8932,6 +9053,24 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>  	return 0;
>  }

and with suggestion in patch 2 the single __process_kf_arg_ptr_to_graph_node helper
called as:

> +static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
> +					   struct bpf_reg_state *reg, u32 regno,
> +					   struct bpf_kfunc_call_arg_meta *meta)
> +{
> +	return __process_kf_arg_ptr_to_graph_node(env, reg, regno, meta,
> +						  BPF_LIST_HEAD, BPF_LIST_NODE,
> +						  &meta->arg_list_head.field);
> +}
> +
> +static int process_kf_arg_ptr_to_rbtree_node(struct bpf_verifier_env *env,
> +					     struct bpf_reg_state *reg, u32 regno,
> +					     struct bpf_kfunc_call_arg_meta *meta)
> +{
> +	return __process_kf_arg_ptr_to_graph_node(env, reg, regno, meta,
> +						  BPF_RB_ROOT, BPF_RB_NODE,
> +						  &meta->arg_rbtree_root.field);
> +}

would convert the arg from owning to non-owning.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 09/13] bpf: Special verifier handling for bpf_rbtree_{remove, first}
  2022-12-17  8:25 ` [PATCH v2 bpf-next 09/13] bpf: Special verifier handling for bpf_rbtree_{remove, first} Dave Marchevsky
@ 2022-12-29  4:02   ` Alexei Starovoitov
  0 siblings, 0 replies; 37+ messages in thread
From: Alexei Starovoitov @ 2022-12-29  4:02 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:25:02AM -0800, Dave Marchevsky wrote:
> Newly-added bpf_rbtree_{remove,first} kfuncs have some special properties
> that require handling in the verifier:
> 
>   * both bpf_rbtree_remove and bpf_rbtree_first return the type containing
>     the bpf_rb_node field, with the offset set to that field's offset,
>     instead of a struct bpf_rb_node *
>     * mark_reg_graph_node helper added in previous patch generalizes
>       this logic, use it
> 
>   * bpf_rbtree_remove's node input is a node that's been inserted
>     in the tree - a non-owning reference.
> 
>   * bpf_rbtree_remove must invalidate non-owning references in order to
>     avoid aliasing issue. Add KF_INVALIDATE_NON_OWN flag, which
>     indicates that the marked kfunc is a non-owning ref invalidation
>     point, and associated verifier logic using previously-added
>     invalidate_non_owning_refs helper.
> 
>   * Unlike other functions, which convert one of their input arg regs to
>     non-owning reference, bpf_rbtree_first takes no arguments and just
>     returns a non-owning reference (possibly null)
>     * For now verifier logic for this is special-cased instead of
>       adding new kfunc flag.
> 
> This patch, along with the previous one, complete special verifier
> handling for all rbtree API functions added in this series.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> ---
>  include/linux/btf.h   |  1 +
>  kernel/bpf/helpers.c  |  2 +-
>  kernel/bpf/verifier.c | 34 ++++++++++++++++++++++++++++------
>  3 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 8aee3f7f4248..3663911bb7c0 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -72,6 +72,7 @@
>  #define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
>  #define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
>  #define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
> +#define KF_INVALIDATE_NON_OWN	(1 << 9) /* kfunc invalidates non-owning refs after return */
>  
>  /*
>   * Return the name of the passed struct, if exists, or halt the build if for
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index de4523c777b7..0e6d010e6423 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -2121,7 +2121,7 @@ BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
>  BTF_ID_FLAGS(func, bpf_task_acquire_not_zero, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
>  BTF_ID_FLAGS(func, bpf_task_kptr_get, KF_ACQUIRE | KF_KPTR_GET | KF_RET_NULL)
>  BTF_ID_FLAGS(func, bpf_task_release, KF_RELEASE)
> -BTF_ID_FLAGS(func, bpf_rbtree_remove, KF_ACQUIRE)
> +BTF_ID_FLAGS(func, bpf_rbtree_remove, KF_ACQUIRE | KF_INVALIDATE_NON_OWN)

I don't like this 'generalization' either.

>  BTF_ID_FLAGS(func, bpf_rbtree_add, KF_RELEASE | KF_RELEASE_NON_OWN)
>  BTF_ID_FLAGS(func, bpf_rbtree_first, KF_RET_NULL)
>  
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 75979f78399d..b4bf3701de7f 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -8393,6 +8393,11 @@ static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
>  	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
>  }
>  
> +static bool is_kfunc_invalidate_non_own(struct bpf_kfunc_call_arg_meta *meta)
> +{
> +	return meta->kfunc_flags & KF_INVALIDATE_NON_OWN;
> +}
> +
>  static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
>  {
>  	return meta->kfunc_flags & KF_TRUSTED_ARGS;
> @@ -9425,10 +9430,20 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  				verbose(env, "arg#%d expected pointer to allocated object\n", i);
>  				return -EINVAL;
>  			}
> -			if (!reg->ref_obj_id) {
> +			if (meta->func_id == special_kfunc_list[KF_bpf_rbtree_remove]) {
> +				if (reg->ref_obj_id) {
> +					verbose(env, "rbtree_remove node input must be non-owning ref\n");
> +					return -EINVAL;
> +				}
> +				if (in_rbtree_lock_required_cb(env)) {
> +					verbose(env, "rbtree_remove not allowed in rbtree cb\n");
> +					return -EINVAL;
> +				}
> +			} else if (!reg->ref_obj_id) {
>  				verbose(env, "allocated object must be referenced\n");
>  				return -EINVAL;
>  			}
> +
>  			ret = process_kf_arg_ptr_to_rbtree_node(env, reg, regno, meta);
>  			if (ret < 0)
>  				return ret;
> @@ -9665,11 +9680,12 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  				   meta.func_id == special_kfunc_list[KF_bpf_list_pop_back]) {
>  				struct btf_field *field = meta.arg_list_head.field;
>  
> -				mark_reg_known_zero(env, regs, BPF_REG_0);
> -				regs[BPF_REG_0].type = PTR_TO_BTF_ID | MEM_ALLOC;
> -				regs[BPF_REG_0].btf = field->graph_root.btf;
> -				regs[BPF_REG_0].btf_id = field->graph_root.value_btf_id;
> -				regs[BPF_REG_0].off = field->graph_root.node_offset;
> +				mark_reg_graph_node(regs, BPF_REG_0, &field->graph_root);
> +			} else if (meta.func_id == special_kfunc_list[KF_bpf_rbtree_remove] ||

Just call invalidate_non_owning_refs() here since it needs to be a special case anyway.

> +				   meta.func_id == special_kfunc_list[KF_bpf_rbtree_first]) {
> +				struct btf_field *field = meta.arg_rbtree_root.field;
> +
> +				mark_reg_graph_node(regs, BPF_REG_0, &field->graph_root);
>  			} else if (meta.func_id == special_kfunc_list[KF_bpf_cast_to_kern_ctx]) {
>  				mark_reg_known_zero(env, regs, BPF_REG_0);
>  				regs[BPF_REG_0].type = PTR_TO_BTF_ID | PTR_TRUSTED;
> @@ -9735,7 +9751,13 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  			if (is_kfunc_ret_null(&meta))
>  				regs[BPF_REG_0].id = id;
>  			regs[BPF_REG_0].ref_obj_id = id;
> +		} else if (meta.func_id == special_kfunc_list[KF_bpf_rbtree_first]) {
> +			ref_set_non_owning_lock(env, &regs[BPF_REG_0]);
>  		}
> +
> +		if (is_kfunc_invalidate_non_own(&meta))
> +			invalidate_non_owning_refs(env, &env->cur_state->active_lock);
> +
>  		if (reg_may_point_to_spin_lock(&regs[BPF_REG_0]) && !regs[BPF_REG_0].id)
>  			regs[BPF_REG_0].id = ++env->id_gen;
>  	} /* else { add_kfunc_call() ensures it is btf_type_is_void(t) } */
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2022-12-17  8:24 ` [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs Dave Marchevsky
  2022-12-29  3:24   ` Alexei Starovoitov
@ 2022-12-29  6:40   ` David Vernet
  2022-12-29 16:50     ` Alexei Starovoitov
  1 sibling, 1 reply; 37+ messages in thread
From: David Vernet @ 2022-12-29  6:40 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Sat, Dec 17, 2022 at 12:24:54AM -0800, Dave Marchevsky wrote:
> Currently, kfuncs marked KF_RELEASE indicate that they release some
> previously-acquired arg. The verifier assumes that such a function will
> only have one arg reg w/ ref_obj_id set, and that that arg is the one to
> be released. Multiple kfunc arg regs have ref_obj_id set is considered
> an invalid state.
> 
> For helpers, RELEASE is used to tag a particular arg in the function
> proto, not the function itself. The arg with OBJ_RELEASE type tag is the
> arg that the helper will release. There can only be one such tagged arg.
> When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
> also considered an invalid state.
> 
> Later patches in this series will result in some linked_list helpers
> marked KF_RELEASE having a valid reason to take two ref_obj_id args.
> Specifically, bpf_list_push_{front,back} can push a node to a list head
> which is itself part of a list node. In such a scenario both arguments
> to these functions would have ref_obj_id > 0, thus would fail
> verification under current logic.
> 
> This patch changes kfunc ref_obj_id searching logic to find the last arg
> reg w/ ref_obj_id and consider that the reg-to-release. This should be
> backwards-compatible with all current kfuncs as they only expect one
> such arg reg.

Can't say I'm a huge fan of this proposal :-( While I think it's really
unfortunate that kfunc flags are not defined per-arg for this exact type
of reason, adding more flag-specific semantics like this is IMO a step
in the wrong direction.  It's similar to the existing __sz and __k
argument-naming semantics that inform the verifier that the arguments
have special meaning. All of these little additions of special-case
handling for kfunc flags end up requiring people writing kfuncs (and
sometimes calling them) to read through the verifier to understand
what's going on (though I will say that it's nice that __sz and __k are
properly documented in [0]).

[0]: https://docs.kernel.org/bpf/kfuncs.html#sz-annotation

The correct thing to do here, in my opinion, is to work to combine kfunc
and helper definitions. Right now that's of course not possible for a
number of reasons, including the fact that kfuncs can do things that
helpers cannot. If we do end up merging it, at the very least I'd ask
you to please loudly document the behavior both in
Documentation/bpf/kfuncs.rst, and in the code where the kfunc flags are
defined, if you don't mind.

Of course, that's assuming that we decide that we still need this, per
Alexei's comment in [1].

[1]: https://lore.kernel.org/all/20221229032442.dkastsstktsxjymb@MacBook-Pro-6.local/

> 
> Currently the ref_obj_id and OBJ_RELEASE searching is done in the code
> that examines each individual arg (check_func_arg for helpers and
> check_kfunc_args inner loop for kfuncs). This patch pulls out this
> searching to occur before individual arg type handling, resulting in a
> cleaner separation of logic.
> 
> Two new helpers are added:
>   * args_find_ref_obj_id_regno
>     * For helpers and kfuncs. Searches through arg regs to find
>       ref_obj_id reg and returns its regno. Helpers set allow_multi =
>       false, retaining "only one ref_obj_id arg" behavior, while kfuncs
>       set allow_multi = true and get the last ref_obj_id arg reg back.
> 
>   * helper_proto_find_release_arg_regno
>     * For helpers only. Searches through fn proto args to find the
>       OBJ_RELEASE arg and returns the corresponding regno.
> 
> Aside from the intentional semantic change for kfuncs, the rest of the
> refactoring strives to keep failure logic and error messages unchanged.
> However, because the release arg searching is now done before any
> arg-specific type checking, verifier states that are invalid due to both
> invalid release arg state _and_ some type- or helper-specific checking
> might see release arg-related error message first.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> ---
>  kernel/bpf/verifier.c | 206 ++++++++++++++++++++++++++++--------------
>  1 file changed, 138 insertions(+), 68 deletions(-)
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index a5255a0dcbb6..824e2242eae5 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -6412,49 +6412,6 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
>  		return err;
>  
>  skip_type_check:
> -	if (arg_type_is_release(arg_type)) {
> -		if (arg_type_is_dynptr(arg_type)) {
> -			struct bpf_func_state *state = func(env, reg);
> -			int spi;
> -
> -			/* Only dynptr created on stack can be released, thus
> -			 * the get_spi and stack state checks for spilled_ptr
> -			 * should only be done before process_dynptr_func for
> -			 * PTR_TO_STACK.
> -			 */
> -			if (reg->type == PTR_TO_STACK) {
> -				spi = get_spi(reg->off);
> -				if (!is_spi_bounds_valid(state, spi, BPF_DYNPTR_NR_SLOTS) ||
> -				    !state->stack[spi].spilled_ptr.ref_obj_id) {
> -					verbose(env, "arg %d is an unacquired reference\n", regno);
> -					return -EINVAL;
> -				}
> -			} else {
> -				verbose(env, "cannot release unowned const bpf_dynptr\n");
> -				return -EINVAL;
> -			}
> -		} else if (!reg->ref_obj_id && !register_is_null(reg)) {
> -			verbose(env, "R%d must be referenced when passed to release function\n",
> -				regno);
> -			return -EINVAL;
> -		}
> -		if (meta->release_regno) {
> -			verbose(env, "verifier internal error: more than one release argument\n");
> -			return -EFAULT;
> -		}
> -		meta->release_regno = regno;
> -	}
> -
> -	if (reg->ref_obj_id) {
> -		if (meta->ref_obj_id) {
> -			verbose(env, "verifier internal error: more than one arg with ref_obj_id R%d %u %u\n",
> -				regno, reg->ref_obj_id,
> -				meta->ref_obj_id);
> -			return -EFAULT;
> -		}
> -		meta->ref_obj_id = reg->ref_obj_id;
> -	}
> -
>  	switch (base_type(arg_type)) {
>  	case ARG_CONST_MAP_PTR:
>  		/* bpf_map_xxx(map_ptr) call: remember that map_ptr */
> @@ -6565,6 +6522,27 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
>  		err = check_mem_size_reg(env, reg, regno, true, meta);
>  		break;
>  	case ARG_PTR_TO_DYNPTR:
> +		if (meta->release_regno == regno) {
> +			struct bpf_func_state *state = func(env, reg);
> +			int spi;
> +
> +			/* Only dynptr created on stack can be released, thus
> +			 * the get_spi and stack state checks for spilled_ptr
> +			 * should only be done before process_dynptr_func for
> +			 * PTR_TO_STACK.
> +			 */
> +			if (reg->type == PTR_TO_STACK) {
> +				spi = get_spi(reg->off);
> +				if (!is_spi_bounds_valid(state, spi, BPF_DYNPTR_NR_SLOTS) ||
> +				    !state->stack[spi].spilled_ptr.ref_obj_id) {
> +					verbose(env, "arg %d is an unacquired reference\n", regno);
> +					return -EINVAL;
> +				}
> +			} else {
> +				verbose(env, "cannot release unowned const bpf_dynptr\n");
> +				return -EINVAL;
> +			}
> +		}
>  		err = process_dynptr_func(env, regno, arg_type, meta);
>  		if (err)
>  			return err;
> @@ -7699,10 +7677,78 @@ static void update_loop_inline_state(struct bpf_verifier_env *env, u32 subprogno
>  				 state->callback_subprogno == subprogno);
>  }
>  
> +/* Call arg meta's ref_obj_id is used to either:
> + *   - For release funcs, keep track of ref that needs to be released
> + *   - For other funcs, keep track of ref that needs to be propagated to retval
> + *
> + * Find and return:
> + *   - Regno that should become meta->ref_obj_id on success
> + *     (regno > 0 since BPF_REG_1 is first arg)
> + *   - 0 if no arg had ref_obj_id set
> + *   - Negative err if some invalid arg reg state
> + *
> + * allow_multi controls whether multiple args w/ ref_obj_id set is valid
> + *   - true: regno of _last_ such arg reg is returned
> + *   - false: err if multiple args w/ ref_obj_id set are seen
> + */

Could you please update this function header to match the suggested
formatting in the coding style ([1])? Applies to
helper_proto_find_release_arg_regno() as well.

[1]: https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation

> +static int args_find_ref_obj_id_regno(struct bpf_verifier_env *env, struct bpf_reg_state *regs,
> +				      u32 nargs, bool allow_multi)
> +{
> +	struct bpf_reg_state *reg;
> +	u32 i, regno, found_regno = 0;
> +
> +	for (i = 0; i < nargs; i++) {
> +		regno = i + 1;
> +		reg = &regs[regno];
> +
> +		if (!reg->ref_obj_id)
> +			continue;
> +
> +		if (!allow_multi && found_regno) {
> +			verbose(env, "verifier internal error: more than one arg with ref_obj_id R%d %u %u\n",
> +				regno, reg->ref_obj_id, regs[found_regno].ref_obj_id);
> +			return -EFAULT;
> +		}
> +
> +		found_regno = regno;
> +	}
> +
> +	return found_regno;
> +}
> +
> +/* Find the OBJ_RELEASE arg in helper func proto and return:
> + *   - regno of single OBJ_RELEASE arg
> + *   - 0 if no arg in the proto was OBJ_RELEASE
> + *   - Negative err if some invalid func proto state
> + */
> +static int helper_proto_find_release_arg_regno(struct bpf_verifier_env *env,
> +					       const struct bpf_func_proto *fn, u32 nargs)
> +{
> +	enum bpf_arg_type arg_type;
> +	int i, release_regno = 0;
> +
> +	for (i = 0; i < nargs; i++) {
> +		arg_type = fn->arg_type[i];
> +
> +		if (!arg_type_is_release(arg_type))
> +			continue;
> +
> +		if (release_regno) {
> +			verbose(env, "verifier internal error: more than one release argument\n");
> +			return -EFAULT;
> +		}
> +
> +		release_regno = i + BPF_REG_1;
> +	}
> +
> +	return release_regno;
> +}
> +
>  static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  			     int *insn_idx_p)
>  {
>  	enum bpf_prog_type prog_type = resolve_prog_type(env->prog);
> +	int i, err, func_id, nargs, release_regno, ref_regno;
>  	const struct bpf_func_proto *fn = NULL;
>  	enum bpf_return_type ret_type;
>  	enum bpf_type_flag ret_flag;
> @@ -7710,7 +7756,6 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>  	struct bpf_call_arg_meta meta;
>  	int insn_idx = *insn_idx_p;
>  	bool changes_data;
> -	int i, err, func_id;
>  
>  	/* find function prototype */
>  	func_id = insn->imm;
> @@ -7774,8 +7819,38 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>  	}
>  
>  	meta.func_id = func_id;
> +	regs = cur_regs(env);
> +
> +	/* find actual arg count */
> +	for (i = 0; i < MAX_BPF_FUNC_REG_ARGS; i++)
> +		if (fn->arg_type[i] == ARG_DONTCARE)
> +			break;
> +	nargs = i;

Is this just an optimization to avoid unnecessary loop iterations? If
so, can we pull it into a separate patch? Also, you could very slightly
simplify this by doing the for loop over nargs here instead of i. Feel
free to ignore though if you think that will be less readable.

> +
> +	release_regno = helper_proto_find_release_arg_regno(env, fn, nargs);
> +	if (release_regno < 0)
> +		return release_regno;
> +
> +	ref_regno = args_find_ref_obj_id_regno(env, regs, nargs, false);
> +	if (ref_regno < 0)
> +		return ref_regno;

Hmm, I'm confused. Why are we tracking two different registers here,
given that it's a helper function so the release argument should be
unambiguous? Can we just get rid of ref_regno and use release_regno
here? Or am I missing something?

Note that I don't think it's necessarily incorrect to pass multiple
arguments with ref_obj_id > 0 to a helper function precisly because
there's no ambiguity as to which argument is being released. One
argument could be a refcounted object that's not being released, and
another could be the object being released. I don't think we have any
such helpers, but conceptually it doesn't seem like something we'd need
to protect against. It's actually kfuncs where it feels problematic to
have multiple ref_obj_id > 0 args due to the inherent ambiguity, though
I realize the intention of this patch is to enable the behavior for
kfuncs.

> +	else if (ref_regno > 0)
> +		meta.ref_obj_id = regs[ref_regno].ref_obj_id;
> +
> +	if (release_regno > 0) {
> +		if (!regs[release_regno].ref_obj_id &&
> +		    !register_is_null(&regs[release_regno]) &&
> +		    !arg_type_is_dynptr(fn->arg_type[release_regno - BPF_REG_1])) {
> +			verbose(env, "R%d must be referenced when passed to release function\n",
> +				release_regno);
> +			return -EINVAL;
> +		}
> +
> +		meta.release_regno = release_regno;
> +	}
> +
>  	/* check args */
> -	for (i = 0; i < MAX_BPF_FUNC_REG_ARGS; i++) {
> +	for (i = 0; i < nargs; i++) {
>  		err = check_func_arg(env, i, &meta, fn);
>  		if (err)
>  			return err;
> @@ -7799,8 +7874,6 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>  			return err;
>  	}
>  
> -	regs = cur_regs(env);
> -
>  	/* This can only be set for PTR_TO_STACK, as CONST_PTR_TO_DYNPTR cannot
>  	 * be reinitialized by any dynptr helper. Hence, mark_stack_slots_dynptr
>  	 * is safe to do directly.
> @@ -8795,10 +8868,11 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>  static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
>  {
>  	const char *func_name = meta->func_name, *ref_tname;
> +	struct bpf_reg_state *regs = cur_regs(env);
>  	const struct btf *btf = meta->btf;
>  	const struct btf_param *args;
>  	u32 i, nargs;
> -	int ret;
> +	int ret, ref_regno;
>  
>  	args = (const struct btf_param *)(meta->func_proto + 1);
>  	nargs = btf_type_vlen(meta->func_proto);
> @@ -8808,17 +8882,31 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  		return -EINVAL;
>  	}
>  
> +	ref_regno = args_find_ref_obj_id_regno(env, cur_regs(env), nargs, true);
> +	if (ref_regno < 0) {
> +		return ref_regno;
> +	} else if (!ref_regno && is_kfunc_release(meta)) {
> +		verbose(env, "release kernel function %s expects refcounted PTR_TO_BTF_ID\n",
> +			func_name);
> +		return -EINVAL;
> +	}
> +
> +	meta->ref_obj_id = regs[ref_regno].ref_obj_id;
> +	if (is_kfunc_release(meta))
> +		meta->release_regno = ref_regno;
> +
>  	/* Check that BTF function arguments match actual types that the
>  	 * verifier sees.
>  	 */
>  	for (i = 0; i < nargs; i++) {
> -		struct bpf_reg_state *regs = cur_regs(env), *reg = &regs[i + 1];
>  		const struct btf_type *t, *ref_t, *resolve_ret;
>  		enum bpf_arg_type arg_type = ARG_DONTCARE;
>  		u32 regno = i + 1, ref_id, type_size;
>  		bool is_ret_buf_sz = false;
> +		struct bpf_reg_state *reg;
>  		int kf_arg_type;
>  
> +		reg = &regs[regno];
>  		t = btf_type_skip_modifiers(btf, args[i].type, NULL);
>  
>  		if (is_kfunc_arg_ignore(btf, &args[i]))
> @@ -8875,18 +8963,6 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  			return -EINVAL;
>  		}
>  
> -		if (reg->ref_obj_id) {
> -			if (is_kfunc_release(meta) && meta->ref_obj_id) {
> -				verbose(env, "verifier internal error: more than one arg with ref_obj_id R%d %u %u\n",
> -					regno, reg->ref_obj_id,
> -					meta->ref_obj_id);
> -				return -EFAULT;
> -			}
> -			meta->ref_obj_id = reg->ref_obj_id;
> -			if (is_kfunc_release(meta))
> -				meta->release_regno = regno;
> -		}
> -
>  		ref_t = btf_type_skip_modifiers(btf, t->type, &ref_id);
>  		ref_tname = btf_name_by_offset(btf, ref_t->name_off);
>  
> @@ -8929,7 +9005,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  			return -EFAULT;
>  		}
>  
> -		if (is_kfunc_release(meta) && reg->ref_obj_id)
> +		if (is_kfunc_release(meta) && regno == meta->release_regno)
>  			arg_type |= OBJ_RELEASE;
>  		ret = check_func_arg_reg_off(env, reg, regno, arg_type);
>  		if (ret < 0)
> @@ -9049,12 +9125,6 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  		}
>  	}
>  
> -	if (is_kfunc_release(meta) && !meta->release_regno) {
> -		verbose(env, "release kernel function %s expects refcounted PTR_TO_BTF_ID\n",
> -			func_name);
> -		return -EINVAL;
> -	}
> -
>  	return 0;
>  }
>  
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-28 23:46   ` David Vernet
@ 2022-12-29 15:39     ` David Vernet
  0 siblings, 0 replies; 37+ messages in thread
From: David Vernet @ 2022-12-29 15:39 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Wed, Dec 28, 2022 at 05:46:54PM -0600, David Vernet wrote:

[...]

> Hey Dave,
> 
> I'm sorry to be chiming in a bit late in the game here, but I only
> finally had the time to fully review some of this stuff during the
> holiday-lull, and I have a few questions / concerns about the whole
> owning vs. non-owning refcount approach we're taking here.

After reading through sleeping on this and reading through the
discussion in [0], I have some slight adjustments I want to make to my
points here.

[0]: https://lore.kernel.org/bpf/20221207230602.logjjjv3kwiiy6u3@macbook-pro-6.dhcp.thefacebook.com/

> 
> > ---
> >  include/linux/bpf.h          |   1 +
> >  include/linux/bpf_verifier.h |  39 ++++-----
> >  include/linux/btf.h          |  17 ++--
> >  kernel/bpf/helpers.c         |   4 +-
> >  kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
> >  5 files changed, 146 insertions(+), 79 deletions(-)
> > 
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 3de24cfb7a3d..f71571bf6adc 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -180,6 +180,7 @@ enum btf_field_type {
> >  	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
> >  	BPF_LIST_HEAD  = (1 << 4),
> >  	BPF_LIST_NODE  = (1 << 5),
> > +	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
> >  };
> >  
> >  struct btf_field_kptr {
> > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > index 53d175cbaa02..cb417ffbbb84 100644
> > --- a/include/linux/bpf_verifier.h
> > +++ b/include/linux/bpf_verifier.h
> > @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
> >  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
> >  };
> >  
> > +/* For every reg representing a map value or allocated object pointer,
> > + * we consider the tuple of (ptr, id) for them to be unique in verifier
> > + * context and conside them to not alias each other for the purposes of
> > + * tracking lock state.
> > + */
> > +struct bpf_active_lock {
> > +	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> > +	 * there's no active lock held, and other fields have no
> > +	 * meaning. If non-NULL, it indicates that a lock is held and
> > +	 * id member has the reg->id of the register which can be >= 0.
> > +	 */
> > +	void *ptr;
> > +	/* This will be reg->id */
> > +	u32 id;
> > +};
> > +
> >  struct bpf_reg_state {
> >  	/* Ordering of fields matters.  See states_equal() */
> >  	enum bpf_reg_type type;
> > @@ -68,6 +84,7 @@ struct bpf_reg_state {
> >  		struct {
> >  			struct btf *btf;
> >  			u32 btf_id;
> > +			struct bpf_active_lock non_owning_ref_lock;
> >  		};
> >  
> >  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
> > @@ -223,11 +240,6 @@ struct bpf_reference_state {
> >  	 * exiting a callback function.
> >  	 */
> >  	int callback_ref;
> > -	/* Mark the reference state to release the registers sharing the same id
> > -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
> > -	 * safe to access inside the critical section).
> > -	 */
> > -	bool release_on_unlock;
> >  };
> >  
> >  /* state of the program:
> > @@ -328,21 +340,8 @@ struct bpf_verifier_state {
> >  	u32 branches;
> >  	u32 insn_idx;
> >  	u32 curframe;
> > -	/* For every reg representing a map value or allocated object pointer,
> > -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
> > -	 * context and conside them to not alias each other for the purposes of
> > -	 * tracking lock state.
> > -	 */
> > -	struct {
> > -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> > -		 * there's no active lock held, and other fields have no
> > -		 * meaning. If non-NULL, it indicates that a lock is held and
> > -		 * id member has the reg->id of the register which can be >= 0.
> > -		 */
> > -		void *ptr;
> > -		/* This will be reg->id */
> > -		u32 id;
> > -	} active_lock;
> > +
> > +	struct bpf_active_lock active_lock;
> >  	bool speculative;
> >  	bool active_rcu_lock;
> >  
> > diff --git a/include/linux/btf.h b/include/linux/btf.h
> > index 5f628f323442..8aee3f7f4248 100644
> > --- a/include/linux/btf.h
> > +++ b/include/linux/btf.h
> > @@ -15,10 +15,10 @@
> >  #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
> >  
> >  /* These need to be macros, as the expressions are used in assembler input */
> > -#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
> > -#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
> > -#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
> > -#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
> > +#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
> > +#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
> > +#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
> > +#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
> >  /* Trusted arguments are those which are guaranteed to be valid when passed to
> >   * the kfunc. It is used to enforce that pointers obtained from either acquire
> >   * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
> > @@ -67,10 +67,11 @@
> >   *	return 0;
> >   * }
> >   */
> > -#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
> > -#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
> > -#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
> > -#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
> > +#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
> > +#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
> > +#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
> > +#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
> > +#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
> 
> It would be nice if we could come up with new kfunc flag names that
> don't have 'RELEASE' in it. As is this is arguably a bit of a leaky
> abstraction given that kfunc authors now have to understand a notion of
> "releasing", "releasing but keeping a non-owning ref", and "releasing
> but it must be a non-owning reference". I know that in [0] you mention
> that the notions of owning and non-owning references are entirely
> relegated to graph-type maps, but I disagree. More below.
> 
> [0]: https://lore.kernel.org/all/20221217082506.1570898-14-davemarchevsky@fb.com/

I see now why you said that owning and non-owning were entirely
relegated to graph-type maps. I think the general idea of owning vs.
non-owning references in the context of graph-type maps is reasonable,
but I think the proposal here unintentionally does combine the concepts
due to its naming choices, which is problematic.

I'll briefly say one more thing below, but I'll continue the
conversation on Alexei's email in [1] to keep everything in the same
place. I'll be responding there shortly.

[1]: https://lore.kernel.org/all/20221229035600.m43ayhidfisbl4sq@MacBook-Pro-6.local/

> 
> In general, IMO this muddies the existing, crystal-clear semantics of
> BPF object ownership and refcounting. Usually a "weak" or "non-owning"
> reference is a shadow of a strong reference, and "using" the weak
> reference requires attempting (because it could fail) to temporarily
> promote it to a strong reference. If successful, the object's existence
> is guaranteed until the weak pointer is demoted back to a weak pointer
> and/or the promoted strong pointer is released, and it's perfectly valid
> for an object's lifetime to be extended due to a promoted weak pointer
> not dropping its reference until after all the other strong pointer
> references have been dropped. The key point here is that a pointer's
> safety is entirely dictated by whether or not the holder has or is able
> to acquire a strong reference, and nothing more.
> 
> In contrast, if I understand correctly, in this proposal a "non-owning"
> reference means that the object is guaranteed to be valid due to
> external factors such as a lock being held on the root node of the
> graph, and is used to e.g. signal whether an object has or has not yet
> been added as a node to an rbtree or a list. If so, IMO these are
> completely separate concepts from refcounting, and I don't think we
> should intertwine it with the acquire / release semantics that we
> currently use for ensuring object lifetime.
> 
> Note that weak references are usually (if not always, at least in my
> experience) used to resolve circular dependencies where the reference
> would always be leaked if both sides had a strong reference. I don't
> think that applies here, where instead we're using "owning reference" to
> mean that ownership of the object has not yet been passed to a
> graph-type data structure, and "non-owning reference" to mean that the
> graph now owns the strong reference, but it's still safe to reference
> the object due to it being protected by some external synchronization
> mechanism like a lock. There's no danger of a circular dependency here,
> we just want to provide consistent API semantics.
> 
> If we want to encapsulate notions of "safe due to a lock being held on a
> root node", and "pointer hasn't yet been inserted into the graph", I
> think we should consider adding some entirely separate abstractions. For
> example, something like PTR_GRAPH_STORED on the register type-modifier
> side for signaling whether a pointer has already been stored in a graph,
> and KF_GRAPH_INSERT, KF_GRAPH_REMOVE type kfunc flags for adding and
> removing from graphs respectively. I don't think we'd have to add
> anything at all for ensuring pointer safety from the lock being held, as
> the verifier should be able to figure out that a pointer that was
> inserted with KF_GRAPH_INSERT is safe to reference inside of the locked
> region of the lock associated with the root node. The refcnt of the
> object isn't relevant at all, it's the association of the root node with
> a specific lock.
> 
> >  
> >  /*
> >   * Return the name of the passed struct, if exists, or halt the build if for
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index af30c6cbd65d..e041409779c3 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
> >  #endif
> >  BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
> >  BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
> > -BTF_ID_FLAGS(func, bpf_list_push_front)
> > -BTF_ID_FLAGS(func, bpf_list_push_back)
> > +BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
> > +BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)
> 
> I don't think a helper should specify both of these flags together.
> IIUC, what this is saying is something along the lines of, "Release the
> reference, but rather than actually releasing it, just keep it and
> convert it into a non-owning reference". IMO KF_RELEASE should always
> mean, exclusively, "I'm releasing a previously-acquired strong reference
> to an object", and the expectation should be that the object cannot be
> referenced _at all_ afterwards, unless you happen to have another strong
> reference.
> 
> IMO this is another sign that we should consider going in a different
> direction for owning vs.  non-owning references. I don't think this

I now don't feel that we should be going in a different direction for
owning vs. non-owning as it applies to graphs as you said in [2]. I do
think, however, that we have to revisit some naming choices, and
possibly consider not adding new kfunc flags at all to enable this.
I'll respond on the other thread to Alexei to keep the discussion in one
place.

[2]: https://lore.kernel.org/all/20221229035600.m43ayhidfisbl4sq@MacBook-Pro-6.local/

> makes sense from an object-refcounting perspective, but I readily admit
> that I could be missing a lot of important context here.
> 
> [...]
> 
> Thanks,
> David

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2022-12-29  6:40   ` David Vernet
@ 2022-12-29 16:50     ` Alexei Starovoitov
  2022-12-29 17:00       ` David Vernet
  0 siblings, 1 reply; 37+ messages in thread
From: Alexei Starovoitov @ 2022-12-29 16:50 UTC (permalink / raw)
  To: David Vernet
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Wed, Dec 28, 2022 at 10:40 PM David Vernet <void@manifault.com> wrote:
>
> On Sat, Dec 17, 2022 at 12:24:54AM -0800, Dave Marchevsky wrote:
> > Currently, kfuncs marked KF_RELEASE indicate that they release some
> > previously-acquired arg. The verifier assumes that such a function will
> > only have one arg reg w/ ref_obj_id set, and that that arg is the one to
> > be released. Multiple kfunc arg regs have ref_obj_id set is considered
> > an invalid state.
> >
> > For helpers, RELEASE is used to tag a particular arg in the function
> > proto, not the function itself. The arg with OBJ_RELEASE type tag is the
> > arg that the helper will release. There can only be one such tagged arg.
> > When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
> > also considered an invalid state.
> >
> > Later patches in this series will result in some linked_list helpers
> > marked KF_RELEASE having a valid reason to take two ref_obj_id args.
> > Specifically, bpf_list_push_{front,back} can push a node to a list head
> > which is itself part of a list node. In such a scenario both arguments
> > to these functions would have ref_obj_id > 0, thus would fail
> > verification under current logic.
> >
> > This patch changes kfunc ref_obj_id searching logic to find the last arg
> > reg w/ ref_obj_id and consider that the reg-to-release. This should be
> > backwards-compatible with all current kfuncs as they only expect one
> > such arg reg.
>
> Can't say I'm a huge fan of this proposal :-( While I think it's really
> unfortunate that kfunc flags are not defined per-arg for this exact type
> of reason, adding more flag-specific semantics like this is IMO a step
> in the wrong direction.  It's similar to the existing __sz and __k
> argument-naming semantics that inform the verifier that the arguments
> have special meaning. All of these little additions of special-case
> handling for kfunc flags end up requiring people writing kfuncs (and
> sometimes calling them) to read through the verifier to understand
> what's going on (though I will say that it's nice that __sz and __k are
> properly documented in [0]).

Before getting to pros/cons of KF_* vs name suffix vs helper style
per-arg description...
It's important to highlight that here we're talking about
link list and rb tree kfuncs that are not like other kfuncs.
Majority of kfuncs can be added by subsystems like hid-bpf
without touching the verifier.
Here we're paving the way for graph (aka new gen data structs)
and so far not only kfuncs, but their arg types have to have
special handling inside the verifier.
There is not much yet to generalize and expose as generic KF_
flag or as a name suffix.
Therefore I think it's more appropriate to implement them
with minimal verifier changes and minimal complexity.
There is no 3rd graph algorithm on the horizon after link list
and rbtree. Instead there is a big todo list for
'multi owner graph node' and 'bpf_refcount_t'.
Those will require bigger changes in the verifier,
so I'd like to avoid premature generalization :) as analogous
to premature optimization :)

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-29  3:56   ` Alexei Starovoitov
@ 2022-12-29 16:54     ` David Vernet
  2023-01-17 16:54       ` Dave Marchevsky
  2023-01-17 16:07     ` Dave Marchevsky
  1 sibling, 1 reply; 37+ messages in thread
From: David Vernet @ 2022-12-29 16:54 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Wed, Dec 28, 2022 at 07:56:00PM -0800, Alexei Starovoitov wrote:
> On Sat, Dec 17, 2022 at 12:24:55AM -0800, Dave Marchevsky wrote:
> > This patch introduces non-owning reference semantics to the verifier,
> > specifically linked_list API kfunc handling. release_on_unlock logic for
> > refs is refactored - with small functional changes - to implement these
> > semantics, and bpf_list_push_{front,back} are migrated to use them.
> > 
> > When a list node is pushed to a list, the program still has a pointer to
> > the node:
> > 
> >   n = bpf_obj_new(typeof(*n));
> > 
> >   bpf_spin_lock(&l);
> >   bpf_list_push_back(&l, n);
> >   /* n still points to the just-added node */
> >   bpf_spin_unlock(&l);
> > 
> > What the verifier considers n to be after the push, and thus what can be
> > done with n, are changed by this patch.
> > 
> > Common properties both before/after this patch:
> >   * After push, n is only a valid reference to the node until end of
> >     critical section
> >   * After push, n cannot be pushed to any list
> >   * After push, the program can read the node's fields using n
> 
> correct.
> 
> > Before:
> >   * After push, n retains the ref_obj_id which it received on
> >     bpf_obj_new, but the associated bpf_reference_state's
> >     release_on_unlock field is set to true
> >     * release_on_unlock field and associated logic is used to implement
> >       "n is only a valid ref until end of critical section"
> >   * After push, n cannot be written to, the node must be removed from
> >     the list before writing to its fields
> >   * After push, n is marked PTR_UNTRUSTED
> 
> yep
> 
> > After:
> >   * After push, n's ref is released and ref_obj_id set to 0. The
> >     bpf_reg_state's non_owning_ref_lock struct is populated with the
> >     currently active lock
> >     * non_owning_ref_lock and logic is used to implement "n is only a
> >       valid ref until end of critical section"
> >   * n can be written to (except for special fields e.g. bpf_list_node,
> >     timer, ...)
> >   * No special type flag is added to n after push
> 
> yep.
> Great summary.
> 
> > Summary of specific implementation changes to achieve the above:
> > 
> >   * release_on_unlock field, ref_set_release_on_unlock helper, and logic
> >     to "release on unlock" based on that field are removed
> 
> +1 
> 
> >   * The anonymous active_lock struct used by bpf_verifier_state is
> >     pulled out into a named struct bpf_active_lock.
> ...
> >   * A non_owning_ref_lock field of type bpf_active_lock is added to
> >     bpf_reg_state's PTR_TO_BTF_ID union
> 
> not great. see below.
> 
> >   * Helpers are added to use non_owning_ref_lock to implement non-owning
> >     ref semantics as described above
> >     * invalidate_non_owning_refs - helper to clobber all non-owning refs
> >       matching a particular bpf_active_lock identity. Replaces
> >       release_on_unlock logic in process_spin_lock.
> 
> +1
> 
> >     * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
> >       on current verifier state
> 
> +1
> 
> >     * ref_convert_owning_non_owning - convert owning reference w/
> >       specified ref_obj_id to non-owning references. Setup
> >       non_owning_ref_lock for each reg with that ref_obj_id and 0 out
> >       its ref_obj_id
> 
> +1
> 
> >   * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
> >     KF_RELEASE to indicate that the release arg reg should be converted
> >     to non-owning ref
> >     * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
> >       the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
> >       doing ref_convert_owning_non_owning on the ref first, which
> >       prevents the regs from being clobbered by 0ing out their
> >       ref_obj_ids. The bpf_reference_state itself is still released via
> >       release_reference as a result of the KF_RELEASE flag.
> >     * KF_RELEASE | KF_RELEASE_NON_OWN are added to
> >       bpf_list_push_{front,back}
> 
> And this bit is confusing and not generalizable.

+1 on both counts. If we want to make it generalizable, I think the only
way to do would be to generalize it across different graph map types.
For example, to have kfunc flags like KF_GRAPH_INSERT and
KF_GRAPH_REMOVE which signal to the verifier that "for this graph-type
map which has a spin-lock associated with its root node that I expect to
be held, I've {inserted, removed} the node {to, from} the graph, so
adjust the refcnt / pointer type accordingly and then clean up when the
lock is dropped."

I don't see any reason to add kfunc flags for that though, as the fact
that the pointer in question refers to a node that has a root node that
has a lock associated with it is already itself a special-case scenario.
I think we should just special-case these kfuncs in the verifier as
"graph-type" kfuncs in some static global array(s).  That's probably
less error prone anyways, and I don't see the typical kfunc writer ever
needing to do this.

> As David noticed in his reply KF_RELEASE_NON_OWN is not a great name.
> It's hard to come up with a good name and it won't be generic anyway.
> The ref_convert_owning_non_owning has to be applied to a specific arg.
> The function itself is not KF_RELEASE in the current definition of it.
> The combination of KF_RELEASE|KF_RELEASE_NON_OWN is something new
> that should have been generic, but doesn't really work this way.
> In the next patches rbtree_root/node still has to have all the custom
> logic.
> KF_RELEASE_NON_OWN by itself is a nonsensical flag.

IMO if a flag doesn't make any sense on its own, or even possibly if it
needs to be mutually exclusive with one or more other flags, it is
probably never a correct building block. Even KF_TRUSTED_ARGS doesn't
really make sense, as it's redundant if KF_RCU is specified. This is
fine though, as IIUC our long-term plan is to get rid of KF_TRUSTED_ARGS
and make it the default behavior for all kfuncs (not trying to hijack
this thread with a tangential discussion about KF_TRUSTED_ARGS, just
using this as an opportunity to point out something to keep in mind as
we continue to add kfunc flags down the road).

> Only combination of KF_RELEASE|KF_RELEASE_NON_OWN sort-of kinda makes
> sense, but still hard to understand what releases what.

I agree and I think this is an important point. IMO it is a worse
tradeoff to try to generalize this by complicating the definition of a
reference than it is to keep the refcounting APIs straightforward and
well defined. As a basic building block, having an owning refcount
should mean one thing: that the object will not be destroyed and is safe
to dereference. When you start mixing in these graph-specific notions of
references meaning different things in specific contexts, it compromises
that and makes the API significantly less usable and extensible.

For example, at some point we may decide to add something like a
kptr_weak_ref which would function exactly like an std::weak_ptr, except
of course that it would wrap a kptr_ref instead of an std::shared_ptr.
IMO something like that is a more natural and generalizable building
block that cleanly complements refcounting as it exists today.

> More below.
> 
> > After these changes, linked_list's "release on unlock" logic continues
> > to function as before, except for the semantic differences noted above.
> > The patch immediately following this one makes minor changes to
> > linked_list selftests to account for the differing behavior.
> > 
> > Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> > ---
> >  include/linux/bpf.h          |   1 +
> >  include/linux/bpf_verifier.h |  39 ++++-----
> >  include/linux/btf.h          |  17 ++--
> >  kernel/bpf/helpers.c         |   4 +-
> >  kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
> >  5 files changed, 146 insertions(+), 79 deletions(-)
> > 
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 3de24cfb7a3d..f71571bf6adc 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -180,6 +180,7 @@ enum btf_field_type {
> >  	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
> >  	BPF_LIST_HEAD  = (1 << 4),
> >  	BPF_LIST_NODE  = (1 << 5),
> > +	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,

Can you update the rest of the elements here to keep common indentation?

> >  };
> >  
> >  struct btf_field_kptr {
> > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > index 53d175cbaa02..cb417ffbbb84 100644
> > --- a/include/linux/bpf_verifier.h
> > +++ b/include/linux/bpf_verifier.h
> > @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
> >  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
> >  };
> >  
> > +/* For every reg representing a map value or allocated object pointer,
> > + * we consider the tuple of (ptr, id) for them to be unique in verifier
> > + * context and conside them to not alias each other for the purposes of
> > + * tracking lock state.
> > + */
> > +struct bpf_active_lock {
> > +	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> > +	 * there's no active lock held, and other fields have no
> > +	 * meaning. If non-NULL, it indicates that a lock is held and
> > +	 * id member has the reg->id of the register which can be >= 0.
> > +	 */
> > +	void *ptr;
> > +	/* This will be reg->id */
> > +	u32 id;
> > +};
> > +
> >  struct bpf_reg_state {
> >  	/* Ordering of fields matters.  See states_equal() */
> >  	enum bpf_reg_type type;
> > @@ -68,6 +84,7 @@ struct bpf_reg_state {
> >  		struct {
> >  			struct btf *btf;
> >  			u32 btf_id;
> > +			struct bpf_active_lock non_owning_ref_lock;
> 
> In your other email you argue that pointer should be enough.
> I suspect that won't be correct.
> See fixes that Andrii did in states_equal() and regsafe().
> In particular:
>         if (!!old->active_lock.id != !!cur->active_lock.id)
>                 return false;
> 
>         if (old->active_lock.id &&
>             !check_ids(old->active_lock.id, cur->active_lock.id, env->idmap_scratch))
>                 return false;
> 
> We have to do the comparison of this new ID via idmap as well.
> 
> I think introduction of struct bpf_active_lock  and addition of it
> to bpf_reg_state is overkill.
> Here we can add 'u32 non_own_ref_obj_id;' only and compare it via idmap in regsafe().
> I'm guessing you didn't like my 'active_lock_id' suggestion. Fine.
> non_own_ref_obj_id would match existing ref_obj_id at least.
> 
> >  		};
> >  
> >  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
> > @@ -223,11 +240,6 @@ struct bpf_reference_state {
> >  	 * exiting a callback function.
> >  	 */
> >  	int callback_ref;
> > -	/* Mark the reference state to release the registers sharing the same id
> > -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
> > -	 * safe to access inside the critical section).
> > -	 */
> > -	bool release_on_unlock;
> >  };
> >  
> >  /* state of the program:
> > @@ -328,21 +340,8 @@ struct bpf_verifier_state {
> >  	u32 branches;
> >  	u32 insn_idx;
> >  	u32 curframe;
> > -	/* For every reg representing a map value or allocated object pointer,
> > -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
> > -	 * context and conside them to not alias each other for the purposes of
> > -	 * tracking lock state.
> > -	 */
> > -	struct {
> > -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
> > -		 * there's no active lock held, and other fields have no
> > -		 * meaning. If non-NULL, it indicates that a lock is held and
> > -		 * id member has the reg->id of the register which can be >= 0.
> > -		 */
> > -		void *ptr;
> > -		/* This will be reg->id */
> > -		u32 id;
> > -	} active_lock;
> 
> I would keep it as-is.
> 
> > +
> > +	struct bpf_active_lock active_lock;
> >  	bool speculative;
> >  	bool active_rcu_lock;
> >  
> > diff --git a/include/linux/btf.h b/include/linux/btf.h
> > index 5f628f323442..8aee3f7f4248 100644
> > --- a/include/linux/btf.h
> > +++ b/include/linux/btf.h
> > @@ -15,10 +15,10 @@
> >  #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
> >  
> >  /* These need to be macros, as the expressions are used in assembler input */
> > -#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
> > -#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
> > -#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
> > -#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
> > +#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
> > +#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
> > +#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
> > +#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
> >  /* Trusted arguments are those which are guaranteed to be valid when passed to
> >   * the kfunc. It is used to enforce that pointers obtained from either acquire
> >   * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
> > @@ -67,10 +67,11 @@
> >   *	return 0;
> >   * }
> >   */
> > -#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
> > -#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
> > -#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
> > -#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
> > +#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
> > +#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
> > +#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
> > +#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
> > +#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
> 
> No need for this flag.
> 
> >  /*
> >   * Return the name of the passed struct, if exists, or halt the build if for
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index af30c6cbd65d..e041409779c3 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
> >  #endif
> >  BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
> >  BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
> > -BTF_ID_FLAGS(func, bpf_list_push_front)
> > -BTF_ID_FLAGS(func, bpf_list_push_back)
> > +BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
> > +BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)
> 
> No need for this.
> 
> >  BTF_ID_FLAGS(func, bpf_list_pop_front, KF_ACQUIRE | KF_RET_NULL)
> >  BTF_ID_FLAGS(func, bpf_list_pop_back, KF_ACQUIRE | KF_RET_NULL)
> >  BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 824e2242eae5..84b0660e2a76 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -190,6 +190,10 @@ struct bpf_verifier_stack_elem {
> >  
> >  static int acquire_reference_state(struct bpf_verifier_env *env, int insn_idx);
> >  static int release_reference(struct bpf_verifier_env *env, int ref_obj_id);
> > +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
> > +				       struct bpf_active_lock *lock);
> > +static int ref_set_non_owning_lock(struct bpf_verifier_env *env,
> > +				   struct bpf_reg_state *reg);
> >  
> >  static bool bpf_map_ptr_poisoned(const struct bpf_insn_aux_data *aux)
> >  {
> > @@ -931,6 +935,9 @@ static void print_verifier_state(struct bpf_verifier_env *env,
> >  				verbose_a("id=%d", reg->id);
> >  			if (reg->ref_obj_id)
> >  				verbose_a("ref_obj_id=%d", reg->ref_obj_id);
> > +			if (reg->non_owning_ref_lock.ptr)
> > +				verbose_a("non_own_id=(%p,%d)", reg->non_owning_ref_lock.ptr,
> > +					  reg->non_owning_ref_lock.id);
> >  			if (t != SCALAR_VALUE)
> >  				verbose_a("off=%d", reg->off);
> >  			if (type_is_pkt_pointer(t))
> > @@ -4820,7 +4827,8 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
> >  			return -EACCES;
> >  		}
> >  
> > -		if (type_is_alloc(reg->type) && !reg->ref_obj_id) {
> > +		if (type_is_alloc(reg->type) && !reg->ref_obj_id &&
> > +		    !reg->non_owning_ref_lock.ptr) {
> >  			verbose(env, "verifier internal error: ref_obj_id for allocated object must be non-zero\n");
> >  			return -EFAULT;
> >  		}
> > @@ -5778,9 +5786,7 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
> >  			cur->active_lock.ptr = btf;
> >  		cur->active_lock.id = reg->id;
> >  	} else {
> > -		struct bpf_func_state *fstate = cur_func(env);
> >  		void *ptr;
> > -		int i;
> >  
> >  		if (map)
> >  			ptr = map;
> > @@ -5796,25 +5802,11 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
> >  			verbose(env, "bpf_spin_unlock of different lock\n");
> >  			return -EINVAL;
> >  		}
> > -		cur->active_lock.ptr = NULL;
> > -		cur->active_lock.id = 0;
> >  
> > -		for (i = fstate->acquired_refs - 1; i >= 0; i--) {
> > -			int err;
> > +		invalidate_non_owning_refs(env, &cur->active_lock);
> 
> +1
> 
> > -			/* Complain on error because this reference state cannot
> > -			 * be freed before this point, as bpf_spin_lock critical
> > -			 * section does not allow functions that release the
> > -			 * allocated object immediately.
> > -			 */
> > -			if (!fstate->refs[i].release_on_unlock)
> > -				continue;
> > -			err = release_reference(env, fstate->refs[i].id);
> > -			if (err) {
> > -				verbose(env, "failed to release release_on_unlock reference");
> > -				return err;
> > -			}
> > -		}
> > +		cur->active_lock.ptr = NULL;
> > +		cur->active_lock.id = 0;
> 
> +1
> 
> >  	}
> >  	return 0;
> >  }
> > @@ -6273,6 +6265,23 @@ static int check_reg_type(struct bpf_verifier_env *env, u32 regno,
> >  	return 0;
> >  }
> >  
> > +static struct btf_field *
> > +reg_find_field_offset(const struct bpf_reg_state *reg, s32 off, u32 fields)
> > +{
> > +	struct btf_field *field;
> > +	struct btf_record *rec;
> > +
> > +	rec = reg_btf_record(reg);
> > +	if (!reg)
> > +		return NULL;
> > +
> > +	field = btf_record_find(rec, off, fields);
> > +	if (!field)
> > +		return NULL;
> > +
> > +	return field;
> > +}
> 
> Doesn't look like that this helper is really necessary.
> 
> > +
> >  int check_func_arg_reg_off(struct bpf_verifier_env *env,
> >  			   const struct bpf_reg_state *reg, int regno,
> >  			   enum bpf_arg_type arg_type)
> > @@ -6294,6 +6303,18 @@ int check_func_arg_reg_off(struct bpf_verifier_env *env,
> >  		 */
> >  		if (arg_type_is_dynptr(arg_type) && type == PTR_TO_STACK)
> >  			return 0;
> > +
> > +		if (type == (PTR_TO_BTF_ID | MEM_ALLOC) && reg->off) {
> > +			if (reg_find_field_offset(reg, reg->off, BPF_GRAPH_NODE_OR_ROOT))
> > +				return __check_ptr_off_reg(env, reg, regno, true);
> > +
> > +			verbose(env, "R%d must have zero offset when passed to release func\n",
> > +				regno);
> > +			verbose(env, "No graph node or root found at R%d type:%s off:%d\n", regno,
> > +				kernel_type_name(reg->btf, reg->btf_id), reg->off);
> > +			return -EINVAL;
> > +		}
> 
> This bit is only necessary if we mark push_list as KF_RELEASE.
> Just don't add this mark and drop above.
> 
> > +
> >  		/* Doing check_ptr_off_reg check for the offset will catch this
> >  		 * because fixed_off_ok is false, but checking here allows us
> >  		 * to give the user a better error message.
> > @@ -7055,6 +7076,20 @@ static int release_reference(struct bpf_verifier_env *env,
> >  	return 0;
> >  }
> >  
> > +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
> > +				       struct bpf_active_lock *lock)
> > +{
> > +	struct bpf_func_state *unused;
> > +	struct bpf_reg_state *reg;
> > +
> > +	bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
> > +		if (reg->non_owning_ref_lock.ptr &&
> > +		    reg->non_owning_ref_lock.ptr == lock->ptr &&
> > +		    reg->non_owning_ref_lock.id == lock->id)
> 
> I think the lock.ptr = lock->ptr comparison is unnecessary to invalidate things.
> We're under active spin_lock here. All regs were checked earlier and id keeps incrementing.
> So we can just do 'u32 non_own_ref_obj_id'.
> 
> > +			__mark_reg_unknown(env, reg);
> > +	}));
> > +}
> > +
> >  static void clear_caller_saved_regs(struct bpf_verifier_env *env,
> >  				    struct bpf_reg_state *regs)
> >  {
> > @@ -8266,6 +8301,11 @@ static bool is_kfunc_release(struct bpf_kfunc_call_arg_meta *meta)
> >  	return meta->kfunc_flags & KF_RELEASE;
> >  }
> >  
> > +static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
> > +{
> > +	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
> > +}
> > +
> 
> No need.
> 
> >  static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
> >  {
> >  	return meta->kfunc_flags & KF_TRUSTED_ARGS;
> > @@ -8651,38 +8691,55 @@ static int process_kf_arg_ptr_to_kptr(struct bpf_verifier_env *env,
> >  	return 0;
> >  }
> >  
> > -static int ref_set_release_on_unlock(struct bpf_verifier_env *env, u32 ref_obj_id)
> > +static int ref_set_non_owning_lock(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
> >  {
> > -	struct bpf_func_state *state = cur_func(env);
> > +	struct bpf_verifier_state *state = env->cur_state;
> > +
> > +	if (!state->active_lock.ptr) {
> > +		verbose(env, "verifier internal error: ref_set_non_owning_lock w/o active lock\n");
> > +		return -EFAULT;
> > +	}
> > +
> > +	if (reg->non_owning_ref_lock.ptr) {
> > +		verbose(env, "verifier internal error: non_owning_ref_lock already set\n");
> > +		return -EFAULT;
> > +	}
> > +
> > +	reg->non_owning_ref_lock.id = state->active_lock.id;
> > +	reg->non_owning_ref_lock.ptr = state->active_lock.ptr;
> > +	return 0;
> > +}
> > +
> > +static int ref_convert_owning_non_owning(struct bpf_verifier_env *env, u32 ref_obj_id)
> > +{
> > +	struct bpf_func_state *state, *unused;
> >  	struct bpf_reg_state *reg;
> >  	int i;
> >  
> > -	/* bpf_spin_lock only allows calling list_push and list_pop, no BPF
> > -	 * subprogs, no global functions. This means that the references would
> > -	 * not be released inside the critical section but they may be added to
> > -	 * the reference state, and the acquired_refs are never copied out for a
> > -	 * different frame as BPF to BPF calls don't work in bpf_spin_lock
> > -	 * critical sections.
> > -	 */
> > +	state = cur_func(env);
> > +
> >  	if (!ref_obj_id) {
> > -		verbose(env, "verifier internal error: ref_obj_id is zero for release_on_unlock\n");
> > +		verbose(env, "verifier internal error: ref_obj_id is zero for "
> > +			     "owning -> non-owning conversion\n");
> >  		return -EFAULT;
> >  	}
> > +
> >  	for (i = 0; i < state->acquired_refs; i++) {
> > -		if (state->refs[i].id == ref_obj_id) {
> > -			if (state->refs[i].release_on_unlock) {
> > -				verbose(env, "verifier internal error: expected false release_on_unlock");
> > -				return -EFAULT;
> > +		if (state->refs[i].id != ref_obj_id)
> > +			continue;
> > +
> > +		/* Clear ref_obj_id here so release_reference doesn't clobber
> > +		 * the whole reg
> > +		 */
> > +		bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
> > +			if (reg->ref_obj_id == ref_obj_id) {
> > +				reg->ref_obj_id = 0;
> > +				ref_set_non_owning_lock(env, reg);
> 
> +1 except ref_set_... name doesn't quite fit. reg_set_... is more accurate, no?
> and probably reg_set_non_own_ref_obj_id() ?
> Or just open code it?
> 
> >  			}
> > -			state->refs[i].release_on_unlock = true;
> > -			/* Now mark everyone sharing same ref_obj_id as untrusted */
> > -			bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
> > -				if (reg->ref_obj_id == ref_obj_id)
> > -					reg->type |= PTR_UNTRUSTED;
> > -			}));
> > -			return 0;
> > -		}
> > +		}));
> > +		return 0;
> >  	}
> > +
> >  	verbose(env, "verifier internal error: ref state missing for ref_obj_id\n");
> >  	return -EFAULT;
> >  }
> > @@ -8817,7 +8874,6 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
> >  {
> >  	const struct btf_type *et, *t;
> >  	struct btf_field *field;
> > -	struct btf_record *rec;
> >  	u32 list_node_off;
> >  
> >  	if (meta->btf != btf_vmlinux ||
> > @@ -8834,9 +8890,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
> >  		return -EINVAL;
> >  	}
> >  
> > -	rec = reg_btf_record(reg);
> >  	list_node_off = reg->off + reg->var_off.value;
> > -	field = btf_record_find(rec, list_node_off, BPF_LIST_NODE);
> > +	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
> >  	if (!field || field->offset != list_node_off) {
> >  		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
> >  		return -EINVAL;
> > @@ -8861,8 +8916,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
> >  			btf_name_by_offset(field->list_head.btf, et->name_off));
> >  		return -EINVAL;
> >  	}
> > -	/* Set arg#1 for expiration after unlock */
> > -	return ref_set_release_on_unlock(env, reg->ref_obj_id);
> > +
> > +	return 0;
> 
> and here we come to the main point.
> Can you just call
> ref_convert_owning_non_owning(env, reg->ref_obj_id) and release_reference() here?
> Everything will be so much simpler, no?
> 
> >  }
> >  
> >  static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
> > @@ -9132,11 +9187,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> >  			    int *insn_idx_p)
> >  {
> >  	const struct btf_type *t, *func, *func_proto, *ptr_type;
> > +	u32 i, nargs, func_id, ptr_type_id, release_ref_obj_id;
> >  	struct bpf_reg_state *regs = cur_regs(env);
> >  	const char *func_name, *ptr_type_name;
> >  	bool sleepable, rcu_lock, rcu_unlock;
> >  	struct bpf_kfunc_call_arg_meta meta;
> > -	u32 i, nargs, func_id, ptr_type_id;
> >  	int err, insn_idx = *insn_idx_p;
> >  	const struct btf_param *args;
> >  	const struct btf_type *ret_t;
> > @@ -9223,7 +9278,18 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> >  	 * PTR_TO_BTF_ID in bpf_kfunc_arg_meta, do the release now.
> >  	 */
> >  	if (meta.release_regno) {
> > -		err = release_reference(env, regs[meta.release_regno].ref_obj_id);
> > +		err = 0;
> > +		release_ref_obj_id = regs[meta.release_regno].ref_obj_id;
> > +
> > +		if (is_kfunc_release_non_own(&meta))
> > +			err = ref_convert_owning_non_owning(env, release_ref_obj_id);
> > +		if (err) {
> > +			verbose(env, "kfunc %s#%d conversion of owning ref to non-owning failed\n",
> > +				func_name, func_id);
> > +			return err;
> > +		}
> > +
> > +		err = release_reference(env, release_ref_obj_id);
> 
> and this bit won't be needed.
> and no need to guess in patch 1 which arg has to be released and converted to non_own.
> 
> >  		if (err) {
> >  			verbose(env, "kfunc %s#%d reference has not been acquired before\n",
> >  				func_name, func_id);
> > -- 
> > 2.30.2
> > 

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2022-12-29 16:50     ` Alexei Starovoitov
@ 2022-12-29 17:00       ` David Vernet
  2023-01-17 17:26         ` Dave Marchevsky
  0 siblings, 1 reply; 37+ messages in thread
From: David Vernet @ 2022-12-29 17:00 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Thu, Dec 29, 2022 at 08:50:19AM -0800, Alexei Starovoitov wrote:
> On Wed, Dec 28, 2022 at 10:40 PM David Vernet <void@manifault.com> wrote:
> >
> > On Sat, Dec 17, 2022 at 12:24:54AM -0800, Dave Marchevsky wrote:
> > > Currently, kfuncs marked KF_RELEASE indicate that they release some
> > > previously-acquired arg. The verifier assumes that such a function will
> > > only have one arg reg w/ ref_obj_id set, and that that arg is the one to
> > > be released. Multiple kfunc arg regs have ref_obj_id set is considered
> > > an invalid state.
> > >
> > > For helpers, RELEASE is used to tag a particular arg in the function
> > > proto, not the function itself. The arg with OBJ_RELEASE type tag is the
> > > arg that the helper will release. There can only be one such tagged arg.
> > > When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
> > > also considered an invalid state.
> > >
> > > Later patches in this series will result in some linked_list helpers
> > > marked KF_RELEASE having a valid reason to take two ref_obj_id args.
> > > Specifically, bpf_list_push_{front,back} can push a node to a list head
> > > which is itself part of a list node. In such a scenario both arguments
> > > to these functions would have ref_obj_id > 0, thus would fail
> > > verification under current logic.
> > >
> > > This patch changes kfunc ref_obj_id searching logic to find the last arg
> > > reg w/ ref_obj_id and consider that the reg-to-release. This should be
> > > backwards-compatible with all current kfuncs as they only expect one
> > > such arg reg.
> >
> > Can't say I'm a huge fan of this proposal :-( While I think it's really
> > unfortunate that kfunc flags are not defined per-arg for this exact type
> > of reason, adding more flag-specific semantics like this is IMO a step
> > in the wrong direction.  It's similar to the existing __sz and __k
> > argument-naming semantics that inform the verifier that the arguments
> > have special meaning. All of these little additions of special-case
> > handling for kfunc flags end up requiring people writing kfuncs (and
> > sometimes calling them) to read through the verifier to understand
> > what's going on (though I will say that it's nice that __sz and __k are
> > properly documented in [0]).
> 
> Before getting to pros/cons of KF_* vs name suffix vs helper style
> per-arg description...
> It's important to highlight that here we're talking about
> link list and rb tree kfuncs that are not like other kfuncs.
> Majority of kfuncs can be added by subsystems like hid-bpf
> without touching the verifier.

I hear you and I agree. It wasn't my intention to drag us into a larger
discussion about kfuncs vs. helpers, but rather just to point out that I
think we have to try hard to avoid adding special-case logic that
requires looking into the verifier to understand the semantics. I think
we're on the same page about this, based on this and your other
response.

> Here we're paving the way for graph (aka new gen data structs)
> and so far not only kfuncs, but their arg types have to have
> special handling inside the verifier.
> There is not much yet to generalize and expose as generic KF_
> flag or as a name suffix.
> Therefore I think it's more appropriate to implement them
> with minimal verifier changes and minimal complexity.

Agreed

> There is no 3rd graph algorithm on the horizon after link list
> and rbtree. Instead there is a big todo list for
> 'multi owner graph node' and 'bpf_refcount_t'.

In this case my point in [0] of the only option for generalizing being
to have something like KF_GRAPH_INSERT / KF_GRAPH_REMOVE is just not the
way forward (which I also said was my opinion when I pointed it out as
an option). Let's just special-case these kfuncs. There's already a
precedence for doing that in the verifier anyways. Minimal complexity,
minimal API changes. It's a win-win.

[0]: https://lore.kernel.org/all/Y63GLqZil9l1NzY4@maniforge.lan/

> Those will require bigger changes in the verifier,
> so I'd like to avoid premature generalization :) as analogous
> to premature optimization :)

And of course given my points above and in other threads: agreed. I
think we have an ideal middle-ground for minimizing complexity in the
short term, and some nice follow-on todo-list items to work on in the
medium-long term which will continue to improve things without
(negatively) affecting users in any way. All SGTM

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-29  3:56   ` Alexei Starovoitov
  2022-12-29 16:54     ` David Vernet
@ 2023-01-17 16:07     ` Dave Marchevsky
  2023-01-17 16:56       ` Alexei Starovoitov
  1 sibling, 1 reply; 37+ messages in thread
From: Dave Marchevsky @ 2023-01-17 16:07 UTC (permalink / raw)
  To: Alexei Starovoitov, Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On 12/28/22 10:56 PM, Alexei Starovoitov wrote:
> On Sat, Dec 17, 2022 at 12:24:55AM -0800, Dave Marchevsky wrote:
>> This patch introduces non-owning reference semantics to the verifier,
>> specifically linked_list API kfunc handling. release_on_unlock logic for
>> refs is refactored - with small functional changes - to implement these
>> semantics, and bpf_list_push_{front,back} are migrated to use them.
>>
>> When a list node is pushed to a list, the program still has a pointer to
>> the node:
>>
>>   n = bpf_obj_new(typeof(*n));
>>
>>   bpf_spin_lock(&l);
>>   bpf_list_push_back(&l, n);
>>   /* n still points to the just-added node */
>>   bpf_spin_unlock(&l);
>>
>> What the verifier considers n to be after the push, and thus what can be
>> done with n, are changed by this patch.
>>
>> Common properties both before/after this patch:
>>   * After push, n is only a valid reference to the node until end of
>>     critical section
>>   * After push, n cannot be pushed to any list
>>   * After push, the program can read the node's fields using n
> 
> correct.
> 
>> Before:
>>   * After push, n retains the ref_obj_id which it received on
>>     bpf_obj_new, but the associated bpf_reference_state's
>>     release_on_unlock field is set to true
>>     * release_on_unlock field and associated logic is used to implement
>>       "n is only a valid ref until end of critical section"
>>   * After push, n cannot be written to, the node must be removed from
>>     the list before writing to its fields
>>   * After push, n is marked PTR_UNTRUSTED
> 
> yep
> 
>> After:
>>   * After push, n's ref is released and ref_obj_id set to 0. The
>>     bpf_reg_state's non_owning_ref_lock struct is populated with the
>>     currently active lock
>>     * non_owning_ref_lock and logic is used to implement "n is only a
>>       valid ref until end of critical section"
>>   * n can be written to (except for special fields e.g. bpf_list_node,
>>     timer, ...)
>>   * No special type flag is added to n after push
> 
> yep.
> Great summary.
> 
>> Summary of specific implementation changes to achieve the above:
>>
>>   * release_on_unlock field, ref_set_release_on_unlock helper, and logic
>>     to "release on unlock" based on that field are removed
> 
> +1 
> 
>>   * The anonymous active_lock struct used by bpf_verifier_state is
>>     pulled out into a named struct bpf_active_lock.
> ...
>>   * A non_owning_ref_lock field of type bpf_active_lock is added to
>>     bpf_reg_state's PTR_TO_BTF_ID union
> 
> not great. see below.
> 
>>   * Helpers are added to use non_owning_ref_lock to implement non-owning
>>     ref semantics as described above
>>     * invalidate_non_owning_refs - helper to clobber all non-owning refs
>>       matching a particular bpf_active_lock identity. Replaces
>>       release_on_unlock logic in process_spin_lock.
> 
> +1
> 
>>     * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
>>       on current verifier state
> 
> +1
> 
>>     * ref_convert_owning_non_owning - convert owning reference w/
>>       specified ref_obj_id to non-owning references. Setup
>>       non_owning_ref_lock for each reg with that ref_obj_id and 0 out
>>       its ref_obj_id
> 
> +1
> 
>>   * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
>>     KF_RELEASE to indicate that the release arg reg should be converted
>>     to non-owning ref
>>     * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
>>       the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
>>       doing ref_convert_owning_non_owning on the ref first, which
>>       prevents the regs from being clobbered by 0ing out their
>>       ref_obj_ids. The bpf_reference_state itself is still released via
>>       release_reference as a result of the KF_RELEASE flag.
>>     * KF_RELEASE | KF_RELEASE_NON_OWN are added to
>>       bpf_list_push_{front,back}
> 
> And this bit is confusing and not generalizable.
> As David noticed in his reply KF_RELEASE_NON_OWN is not a great name.
> It's hard to come up with a good name and it won't be generic anyway.
> The ref_convert_owning_non_owning has to be applied to a specific arg.
> The function itself is not KF_RELEASE in the current definition of it.
> The combination of KF_RELEASE|KF_RELEASE_NON_OWN is something new
> that should have been generic, but doesn't really work this way.
> In the next patches rbtree_root/node still has to have all the custom
> logic.
> KF_RELEASE_NON_OWN by itself is a nonsensical flag.
> Only combination of KF_RELEASE|KF_RELEASE_NON_OWN sort-of kinda makes
> sense, but still hard to understand what releases what.
> More below.
> 

Addressed below (in response to your 'here we come to the main point'
comment).

>> After these changes, linked_list's "release on unlock" logic continues
>> to function as before, except for the semantic differences noted above.
>> The patch immediately following this one makes minor changes to
>> linked_list selftests to account for the differing behavior.
>>
>> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
>> ---
>>  include/linux/bpf.h          |   1 +
>>  include/linux/bpf_verifier.h |  39 ++++-----
>>  include/linux/btf.h          |  17 ++--
>>  kernel/bpf/helpers.c         |   4 +-
>>  kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
>>  5 files changed, 146 insertions(+), 79 deletions(-)
>>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 3de24cfb7a3d..f71571bf6adc 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -180,6 +180,7 @@ enum btf_field_type {
>>  	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
>>  	BPF_LIST_HEAD  = (1 << 4),
>>  	BPF_LIST_NODE  = (1 << 5),
>> +	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
>>  };
>>  
>>  struct btf_field_kptr {
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index 53d175cbaa02..cb417ffbbb84 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
>>  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
>>  };
>>  
>> +/* For every reg representing a map value or allocated object pointer,
>> + * we consider the tuple of (ptr, id) for them to be unique in verifier
>> + * context and conside them to not alias each other for the purposes of
>> + * tracking lock state.
>> + */
>> +struct bpf_active_lock {
>> +	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
>> +	 * there's no active lock held, and other fields have no
>> +	 * meaning. If non-NULL, it indicates that a lock is held and
>> +	 * id member has the reg->id of the register which can be >= 0.
>> +	 */
>> +	void *ptr;
>> +	/* This will be reg->id */
>> +	u32 id;
>> +};
>> +
>>  struct bpf_reg_state {
>>  	/* Ordering of fields matters.  See states_equal() */
>>  	enum bpf_reg_type type;
>> @@ -68,6 +84,7 @@ struct bpf_reg_state {
>>  		struct {
>>  			struct btf *btf;
>>  			u32 btf_id;
>> +			struct bpf_active_lock non_owning_ref_lock;
> 
> In your other email you argue that pointer should be enough.
> I suspect that won't be correct.
> See fixes that Andrii did in states_equal() and regsafe().
> In particular:
>         if (!!old->active_lock.id != !!cur->active_lock.id)
>                 return false;
> 
>         if (old->active_lock.id &&
>             !check_ids(old->active_lock.id, cur->active_lock.id, env->idmap_scratch))
>                 return false;
> 
> We have to do the comparison of this new ID via idmap as well.
> 
> I think introduction of struct bpf_active_lock  and addition of it
> to bpf_reg_state is overkill.
> Here we can add 'u32 non_own_ref_obj_id;' only and compare it via idmap in regsafe().
> I'm guessing you didn't like my 'active_lock_id' suggestion. Fine.
> non_own_ref_obj_id would match existing ref_obj_id at least.
> 
>>  		};
>>  
>>  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
>> @@ -223,11 +240,6 @@ struct bpf_reference_state {
>>  	 * exiting a callback function.
>>  	 */
>>  	int callback_ref;
>> -	/* Mark the reference state to release the registers sharing the same id
>> -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
>> -	 * safe to access inside the critical section).
>> -	 */
>> -	bool release_on_unlock;
>>  };
>>  
>>  /* state of the program:
>> @@ -328,21 +340,8 @@ struct bpf_verifier_state {
>>  	u32 branches;
>>  	u32 insn_idx;
>>  	u32 curframe;
>> -	/* For every reg representing a map value or allocated object pointer,
>> -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
>> -	 * context and conside them to not alias each other for the purposes of
>> -	 * tracking lock state.
>> -	 */
>> -	struct {
>> -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
>> -		 * there's no active lock held, and other fields have no
>> -		 * meaning. If non-NULL, it indicates that a lock is held and
>> -		 * id member has the reg->id of the register which can be >= 0.
>> -		 */
>> -		void *ptr;
>> -		/* This will be reg->id */
>> -		u32 id;
>> -	} active_lock;
> 
> I would keep it as-is.
> 
>> +
>> +	struct bpf_active_lock active_lock;
>>  	bool speculative;
>>  	bool active_rcu_lock;
>>  
>> diff --git a/include/linux/btf.h b/include/linux/btf.h
>> index 5f628f323442..8aee3f7f4248 100644
>> --- a/include/linux/btf.h
>> +++ b/include/linux/btf.h
>> @@ -15,10 +15,10 @@
>>  #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
>>  
>>  /* These need to be macros, as the expressions are used in assembler input */
>> -#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
>> -#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
>> -#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
>> -#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
>> +#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
>> +#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
>> +#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
>> +#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
>>  /* Trusted arguments are those which are guaranteed to be valid when passed to
>>   * the kfunc. It is used to enforce that pointers obtained from either acquire
>>   * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
>> @@ -67,10 +67,11 @@
>>   *	return 0;
>>   * }
>>   */
>> -#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
>> -#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
>> -#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
>> -#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
>> +#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
>> +#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
>> +#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
>> +#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
>> +#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
> 
> No need for this flag.
> 

Addressed below (in re: your 'here we come to the main point' comment)

>>  /*
>>   * Return the name of the passed struct, if exists, or halt the build if for
>> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
>> index af30c6cbd65d..e041409779c3 100644
>> --- a/kernel/bpf/helpers.c
>> +++ b/kernel/bpf/helpers.c
>> @@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
>>  #endif
>>  BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
>>  BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
>> -BTF_ID_FLAGS(func, bpf_list_push_front)
>> -BTF_ID_FLAGS(func, bpf_list_push_back)
>> +BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
>> +BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)
> 
> No need for this.
> 

Addressed below (in re: your 'here we come to the main point' comment)

>>  BTF_ID_FLAGS(func, bpf_list_pop_front, KF_ACQUIRE | KF_RET_NULL)
>>  BTF_ID_FLAGS(func, bpf_list_pop_back, KF_ACQUIRE | KF_RET_NULL)
>>  BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 824e2242eae5..84b0660e2a76 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -190,6 +190,10 @@ struct bpf_verifier_stack_elem {
>>  
>>  static int acquire_reference_state(struct bpf_verifier_env *env, int insn_idx);
>>  static int release_reference(struct bpf_verifier_env *env, int ref_obj_id);
>> +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
>> +				       struct bpf_active_lock *lock);
>> +static int ref_set_non_owning_lock(struct bpf_verifier_env *env,
>> +				   struct bpf_reg_state *reg);
>>  
>>  static bool bpf_map_ptr_poisoned(const struct bpf_insn_aux_data *aux)
>>  {
>> @@ -931,6 +935,9 @@ static void print_verifier_state(struct bpf_verifier_env *env,
>>  				verbose_a("id=%d", reg->id);
>>  			if (reg->ref_obj_id)
>>  				verbose_a("ref_obj_id=%d", reg->ref_obj_id);
>> +			if (reg->non_owning_ref_lock.ptr)
>> +				verbose_a("non_own_id=(%p,%d)", reg->non_owning_ref_lock.ptr,
>> +					  reg->non_owning_ref_lock.id);
>>  			if (t != SCALAR_VALUE)
>>  				verbose_a("off=%d", reg->off);
>>  			if (type_is_pkt_pointer(t))
>> @@ -4820,7 +4827,8 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
>>  			return -EACCES;
>>  		}
>>  
>> -		if (type_is_alloc(reg->type) && !reg->ref_obj_id) {
>> +		if (type_is_alloc(reg->type) && !reg->ref_obj_id &&
>> +		    !reg->non_owning_ref_lock.ptr) {
>>  			verbose(env, "verifier internal error: ref_obj_id for allocated object must be non-zero\n");
>>  			return -EFAULT;
>>  		}
>> @@ -5778,9 +5786,7 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
>>  			cur->active_lock.ptr = btf;
>>  		cur->active_lock.id = reg->id;
>>  	} else {
>> -		struct bpf_func_state *fstate = cur_func(env);
>>  		void *ptr;
>> -		int i;
>>  
>>  		if (map)
>>  			ptr = map;
>> @@ -5796,25 +5802,11 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
>>  			verbose(env, "bpf_spin_unlock of different lock\n");
>>  			return -EINVAL;
>>  		}
>> -		cur->active_lock.ptr = NULL;
>> -		cur->active_lock.id = 0;
>>  
>> -		for (i = fstate->acquired_refs - 1; i >= 0; i--) {
>> -			int err;
>> +		invalidate_non_owning_refs(env, &cur->active_lock);
> 
> +1
> 
>> -			/* Complain on error because this reference state cannot
>> -			 * be freed before this point, as bpf_spin_lock critical
>> -			 * section does not allow functions that release the
>> -			 * allocated object immediately.
>> -			 */
>> -			if (!fstate->refs[i].release_on_unlock)
>> -				continue;
>> -			err = release_reference(env, fstate->refs[i].id);
>> -			if (err) {
>> -				verbose(env, "failed to release release_on_unlock reference");
>> -				return err;
>> -			}
>> -		}
>> +		cur->active_lock.ptr = NULL;
>> +		cur->active_lock.id = 0;
> 
> +1
> 
>>  	}
>>  	return 0;
>>  }
>> @@ -6273,6 +6265,23 @@ static int check_reg_type(struct bpf_verifier_env *env, u32 regno,
>>  	return 0;
>>  }
>>  
>> +static struct btf_field *
>> +reg_find_field_offset(const struct bpf_reg_state *reg, s32 off, u32 fields)
>> +{
>> +	struct btf_field *field;
>> +	struct btf_record *rec;
>> +
>> +	rec = reg_btf_record(reg);
>> +	if (!reg)
>> +		return NULL;
>> +
>> +	field = btf_record_find(rec, off, fields);
>> +	if (!field)
>> +		return NULL;
>> +
>> +	return field;
>> +}
> 
> Doesn't look like that this helper is really necessary.
> 

The helper is used in other places in the series. It saves some boilerplate
since usually when reg's btf_record is fetched it's just to look for the 
presence of some field.

If all uses of the helper in this patch are removed, I will move the def to
first patch where it's used when I respin.

>> +
>>  int check_func_arg_reg_off(struct bpf_verifier_env *env,
>>  			   const struct bpf_reg_state *reg, int regno,
>>  			   enum bpf_arg_type arg_type)
>> @@ -6294,6 +6303,18 @@ int check_func_arg_reg_off(struct bpf_verifier_env *env,
>>  		 */
>>  		if (arg_type_is_dynptr(arg_type) && type == PTR_TO_STACK)
>>  			return 0;
>> +
>> +		if (type == (PTR_TO_BTF_ID | MEM_ALLOC) && reg->off) {
>> +			if (reg_find_field_offset(reg, reg->off, BPF_GRAPH_NODE_OR_ROOT))
>> +				return __check_ptr_off_reg(env, reg, regno, true);
>> +
>> +			verbose(env, "R%d must have zero offset when passed to release func\n",
>> +				regno);
>> +			verbose(env, "No graph node or root found at R%d type:%s off:%d\n", regno,
>> +				kernel_type_name(reg->btf, reg->btf_id), reg->off);
>> +			return -EINVAL;
>> +		}
> 
> This bit is only necessary if we mark push_list as KF_RELEASE.
> Just don't add this mark and drop above.
> 

Addressed below (in re: your 'here we come to the main point' comment)

>> +
>>  		/* Doing check_ptr_off_reg check for the offset will catch this
>>  		 * because fixed_off_ok is false, but checking here allows us
>>  		 * to give the user a better error message.
>> @@ -7055,6 +7076,20 @@ static int release_reference(struct bpf_verifier_env *env,
>>  	return 0;
>>  }
>>  
>> +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
>> +				       struct bpf_active_lock *lock)
>> +{
>> +	struct bpf_func_state *unused;
>> +	struct bpf_reg_state *reg;
>> +
>> +	bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
>> +		if (reg->non_owning_ref_lock.ptr &&
>> +		    reg->non_owning_ref_lock.ptr == lock->ptr &&
>> +		    reg->non_owning_ref_lock.id == lock->id)
> 
> I think the lock.ptr = lock->ptr comparison is unnecessary to invalidate things.
> We're under active spin_lock here. All regs were checked earlier and id keeps incrementing.
> So we can just do 'u32 non_own_ref_obj_id'.
> 
>> +			__mark_reg_unknown(env, reg);
>> +	}));
>> +}
>> +
>>  static void clear_caller_saved_regs(struct bpf_verifier_env *env,
>>  				    struct bpf_reg_state *regs)
>>  {
>> @@ -8266,6 +8301,11 @@ static bool is_kfunc_release(struct bpf_kfunc_call_arg_meta *meta)
>>  	return meta->kfunc_flags & KF_RELEASE;
>>  }
>>  
>> +static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
>> +{
>> +	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
>> +}
>> +
> 
> No need.
> 

Addressed below (in re: your 'here we come to the main point' comment)

>>  static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
>>  {
>>  	return meta->kfunc_flags & KF_TRUSTED_ARGS;
>> @@ -8651,38 +8691,55 @@ static int process_kf_arg_ptr_to_kptr(struct bpf_verifier_env *env,
>>  	return 0;
>>  }
>>  
>> -static int ref_set_release_on_unlock(struct bpf_verifier_env *env, u32 ref_obj_id)
>> +static int ref_set_non_owning_lock(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
>>  {
>> -	struct bpf_func_state *state = cur_func(env);
>> +	struct bpf_verifier_state *state = env->cur_state;
>> +
>> +	if (!state->active_lock.ptr) {
>> +		verbose(env, "verifier internal error: ref_set_non_owning_lock w/o active lock\n");
>> +		return -EFAULT;
>> +	}
>> +
>> +	if (reg->non_owning_ref_lock.ptr) {
>> +		verbose(env, "verifier internal error: non_owning_ref_lock already set\n");
>> +		return -EFAULT;
>> +	}
>> +
>> +	reg->non_owning_ref_lock.id = state->active_lock.id;
>> +	reg->non_owning_ref_lock.ptr = state->active_lock.ptr;
>> +	return 0;
>> +}
>> +
>> +static int ref_convert_owning_non_owning(struct bpf_verifier_env *env, u32 ref_obj_id)
>> +{
>> +	struct bpf_func_state *state, *unused;
>>  	struct bpf_reg_state *reg;
>>  	int i;
>>  
>> -	/* bpf_spin_lock only allows calling list_push and list_pop, no BPF
>> -	 * subprogs, no global functions. This means that the references would
>> -	 * not be released inside the critical section but they may be added to
>> -	 * the reference state, and the acquired_refs are never copied out for a
>> -	 * different frame as BPF to BPF calls don't work in bpf_spin_lock
>> -	 * critical sections.
>> -	 */
>> +	state = cur_func(env);
>> +
>>  	if (!ref_obj_id) {
>> -		verbose(env, "verifier internal error: ref_obj_id is zero for release_on_unlock\n");
>> +		verbose(env, "verifier internal error: ref_obj_id is zero for "
>> +			     "owning -> non-owning conversion\n");
>>  		return -EFAULT;
>>  	}
>> +
>>  	for (i = 0; i < state->acquired_refs; i++) {
>> -		if (state->refs[i].id == ref_obj_id) {
>> -			if (state->refs[i].release_on_unlock) {
>> -				verbose(env, "verifier internal error: expected false release_on_unlock");
>> -				return -EFAULT;
>> +		if (state->refs[i].id != ref_obj_id)
>> +			continue;
>> +
>> +		/* Clear ref_obj_id here so release_reference doesn't clobber
>> +		 * the whole reg
>> +		 */
>> +		bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
>> +			if (reg->ref_obj_id == ref_obj_id) {
>> +				reg->ref_obj_id = 0;
>> +				ref_set_non_owning_lock(env, reg);
> 
> +1 except ref_set_... name doesn't quite fit. reg_set_... is more accurate, no?
> and probably reg_set_non_own_ref_obj_id() ?
> Or just open code it?
> 

I like reg_set_... Will change

>>  			}
>> -			state->refs[i].release_on_unlock = true;
>> -			/* Now mark everyone sharing same ref_obj_id as untrusted */
>> -			bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
>> -				if (reg->ref_obj_id == ref_obj_id)
>> -					reg->type |= PTR_UNTRUSTED;
>> -			}));
>> -			return 0;
>> -		}
>> +		}));
>> +		return 0;
>>  	}
>> +
>>  	verbose(env, "verifier internal error: ref state missing for ref_obj_id\n");
>>  	return -EFAULT;
>>  }
>> @@ -8817,7 +8874,6 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>>  {
>>  	const struct btf_type *et, *t;
>>  	struct btf_field *field;
>> -	struct btf_record *rec;
>>  	u32 list_node_off;
>>  
>>  	if (meta->btf != btf_vmlinux ||
>> @@ -8834,9 +8890,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>>  		return -EINVAL;
>>  	}
>>  
>> -	rec = reg_btf_record(reg);
>>  	list_node_off = reg->off + reg->var_off.value;
>> -	field = btf_record_find(rec, list_node_off, BPF_LIST_NODE);
>> +	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
>>  	if (!field || field->offset != list_node_off) {
>>  		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
>>  		return -EINVAL;
>> @@ -8861,8 +8916,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>>  			btf_name_by_offset(field->list_head.btf, et->name_off));
>>  		return -EINVAL;
>>  	}
>> -	/* Set arg#1 for expiration after unlock */
>> -	return ref_set_release_on_unlock(env, reg->ref_obj_id);
>> +
>> +	return 0;
> 
> and here we come to the main point.
> Can you just call
> ref_convert_owning_non_owning(env, reg->ref_obj_id) and release_reference() here?
> Everything will be so much simpler, no?
> 

IIUC, your proposal here is what you'd like me to do instead of
KF_RELEASE_NON_OWN kfunc flag. I think all the points you're making are
interrelated, so I'll summarize my understanding of them and reply to them as a
group here.

1) KF_RELEASE_NON_OWN shouldn't depend on KF_RELEASE and thus shouldn't require
   the flags to be used together. Why? It's confusing and KF_RELEASE_NON_OWN
   isn't really doing a 'release' by current KF_RELEASE semantics since it's
   converting to non-owning.

This point seems reasonable to me. KF_RELEASE_NON_OWN wants to do many things
that KF_RELEASE does, and in the same places (e.g. release_reference(),
confirm that there's a referenced arg passed in). Adding KF_RELEASE_NON_OWN
logic as a special-casing of KF_RELEASE logic in a few places reduced amount of
changes to verifier, at the cost of tying the flags together.

That cost doesn't seem worth it if it's confusing to read and muddies the
meaning of 'RELEASE'. So agreed. Will make KF_RELEASE_NON_OWN logic separate
from KF_RELEASE.


2) process_kf_arg_ptr_to_list_node, renamed __process_kf_arg_ptr_to_graph_node
   in further patches in the series, should handle owning -> non-owning
   conversion, instead of relying on a kfunc flag.

This is how the implementation in v1 worked. In [0] both list_head and rb_root
start using same __process_kf_arg_ptr_to_datastructure_node helper, which does
ref_set_release_on_unlock. Then in [1] the ref_set_release_on_unlock call
is moved out of the __process helper because process_kf_arg_ptr_to_rbtree_node
needs to special-case its behavior for bpf_rbtree_remove.

That special casing led me to move away from doing the owning -> non owning
conversion in the process_ helpers. My logic was as follows:

  * process_kf_arg_ptr_to_{list_node,rbtree_node} act on the arg reg when it's
    a specific type, but owning -> non-owning conversion is more of a function-
    level property. e.g. rbtree_add sees an owning rbtree_node and converts it 
    to non-owning, but not all functions which take an owning rbtree_node will
    want to do this.
    * Really it's both an arg/type-level behavior and a function-level behavior.
      stable BPF helper func proto's .arg1_type w/ base type and flags would
      be a better way of expressing this, IMO, as it'd remove the need to search
      for the arg-to-release with the current KF_RELEASE kfunc-level flag.
  * The 'deeper' in arg reg helper functions special-casing based on function is
    , the harder code becomes to understand.
    * Retval special-casing based on function is less confusing since that's
      usually in 'check_kfunc_call' with minimal helper usage. This is why
      I kept some special-cased logic for rbtree_remove retval in this series,
      although ideally there would be a named semantic for that as well.

But as you mention in this patch and others, we can have this be function-level
behavior without adding a new kfunc flag, by special-casing in the appropriate
spots. This suggestion is pretty reasonable to me, but I'd like to make the case
for keeping the named kfunc flags.

I made a mistake when I used 'generalize' to describe the purpose of moving
logic behind kfunc flags. You and David Vernet correctly state that it's not
likely that the logic will be used by many other kfuncs; even other graph
datastructure API kfuncs won't be that numerous, so is it really 'general'
functionality?

Really what I meant by 'generalize' was 'give this behavior a name that clearly
ties it to graph datastructure semantics'. By 'clearly ties it to ...', I mean:

  * It should be obvious that the named semantic is not unique to the particular
    kfunc
  * It should be obvious that the named semantic is tied to other named graph
    datastructure semantics
  * When specific semantics are discussed in the documentation or on the mailing
    list, it should be easy to tie the concept being discussed to some specific
    code without ambiguity

Personally, whenever I see "func_id == BPF_FUNC_whatever" (or kfunc equivalent),
it's not clear to me whether the logic follows is unique to the helper or is due
to the helper being e.g. "special dynptr helper". For this graph ds stuff
specifically, you had trouble understanding what I wanted to do until we stepped
back from the specific implementation and talked about general semantics of
what args / retval look like before / after kfunc call. Since we nailed down the
semantics - in some detail - in earlier convos, and decided to document them
outside of the code, it made sense to me to give them top-level names.

Your (and David's) comment that "KF_RELEASE_NON_OWN is not a great name"
is IMO acknowledgement that giving the semantic a _good_ name would be useful.

How about I try to make the names better in v3 instead of removing the kfunc
flags entirely? If you're still opposed after that, I will instead add helpers
with comments like:

    /* Implement 'release non owning reference' semantic as described by graph
     * ds documentation
     */
     void graph_ds_release_non_own_ref() { ... }

To satisfy my bullets above.

  [0]: lore.kernel.org/bpf/20221206231000.3180914-8-davemarchevsky@fb.com
  [1]: lore.kernel.org/bpf/20221206231000.3180914-10-davemarchevsky@fb.com

>>  }
>>  
>>  static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
>> @@ -9132,11 +9187,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>  			    int *insn_idx_p)
>>  {
>>  	const struct btf_type *t, *func, *func_proto, *ptr_type;
>> +	u32 i, nargs, func_id, ptr_type_id, release_ref_obj_id;
>>  	struct bpf_reg_state *regs = cur_regs(env);
>>  	const char *func_name, *ptr_type_name;
>>  	bool sleepable, rcu_lock, rcu_unlock;
>>  	struct bpf_kfunc_call_arg_meta meta;
>> -	u32 i, nargs, func_id, ptr_type_id;
>>  	int err, insn_idx = *insn_idx_p;
>>  	const struct btf_param *args;
>>  	const struct btf_type *ret_t;
>> @@ -9223,7 +9278,18 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>  	 * PTR_TO_BTF_ID in bpf_kfunc_arg_meta, do the release now.
>>  	 */
>>  	if (meta.release_regno) {
>> -		err = release_reference(env, regs[meta.release_regno].ref_obj_id);
>> +		err = 0;
>> +		release_ref_obj_id = regs[meta.release_regno].ref_obj_id;
>> +
>> +		if (is_kfunc_release_non_own(&meta))
>> +			err = ref_convert_owning_non_owning(env, release_ref_obj_id);
>> +		if (err) {
>> +			verbose(env, "kfunc %s#%d conversion of owning ref to non-owning failed\n",
>> +				func_name, func_id);
>> +			return err;
>> +		}
>> +
>> +		err = release_reference(env, release_ref_obj_id);
> 
> and this bit won't be needed.
> and no need to guess in patch 1 which arg has to be released and converted to non_own.
> 

Addressed above (in re: your 'here we come to the main point' comment)

>>  		if (err) {
>>  			verbose(env, "kfunc %s#%d reference has not been acquired before\n",
>>  				func_name, func_id);
>> -- 
>> 2.30.2
>>

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2022-12-29 16:54     ` David Vernet
@ 2023-01-17 16:54       ` Dave Marchevsky
  0 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2023-01-17 16:54 UTC (permalink / raw)
  To: David Vernet, Alexei Starovoitov
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On 12/29/22 11:54 AM, David Vernet wrote:
> On Wed, Dec 28, 2022 at 07:56:00PM -0800, Alexei Starovoitov wrote:
>> On Sat, Dec 17, 2022 at 12:24:55AM -0800, Dave Marchevsky wrote:
>>> This patch introduces non-owning reference semantics to the verifier,
>>> specifically linked_list API kfunc handling. release_on_unlock logic for
>>> refs is refactored - with small functional changes - to implement these
>>> semantics, and bpf_list_push_{front,back} are migrated to use them.
>>>
>>> When a list node is pushed to a list, the program still has a pointer to
>>> the node:
>>>
>>>   n = bpf_obj_new(typeof(*n));
>>>
>>>   bpf_spin_lock(&l);
>>>   bpf_list_push_back(&l, n);
>>>   /* n still points to the just-added node */
>>>   bpf_spin_unlock(&l);
>>>
>>> What the verifier considers n to be after the push, and thus what can be
>>> done with n, are changed by this patch.
>>>
>>> Common properties both before/after this patch:
>>>   * After push, n is only a valid reference to the node until end of
>>>     critical section
>>>   * After push, n cannot be pushed to any list
>>>   * After push, the program can read the node's fields using n
>>
>> correct.
>>
>>> Before:
>>>   * After push, n retains the ref_obj_id which it received on
>>>     bpf_obj_new, but the associated bpf_reference_state's
>>>     release_on_unlock field is set to true
>>>     * release_on_unlock field and associated logic is used to implement
>>>       "n is only a valid ref until end of critical section"
>>>   * After push, n cannot be written to, the node must be removed from
>>>     the list before writing to its fields
>>>   * After push, n is marked PTR_UNTRUSTED
>>
>> yep
>>
>>> After:
>>>   * After push, n's ref is released and ref_obj_id set to 0. The
>>>     bpf_reg_state's non_owning_ref_lock struct is populated with the
>>>     currently active lock
>>>     * non_owning_ref_lock and logic is used to implement "n is only a
>>>       valid ref until end of critical section"
>>>   * n can be written to (except for special fields e.g. bpf_list_node,
>>>     timer, ...)
>>>   * No special type flag is added to n after push
>>
>> yep.
>> Great summary.
>>
>>> Summary of specific implementation changes to achieve the above:
>>>
>>>   * release_on_unlock field, ref_set_release_on_unlock helper, and logic
>>>     to "release on unlock" based on that field are removed
>>
>> +1 
>>
>>>   * The anonymous active_lock struct used by bpf_verifier_state is
>>>     pulled out into a named struct bpf_active_lock.
>> ...
>>>   * A non_owning_ref_lock field of type bpf_active_lock is added to
>>>     bpf_reg_state's PTR_TO_BTF_ID union
>>
>> not great. see below.
>>
>>>   * Helpers are added to use non_owning_ref_lock to implement non-owning
>>>     ref semantics as described above
>>>     * invalidate_non_owning_refs - helper to clobber all non-owning refs
>>>       matching a particular bpf_active_lock identity. Replaces
>>>       release_on_unlock logic in process_spin_lock.
>>
>> +1
>>
>>>     * ref_set_non_owning_lock - set non_owning_ref_lock for a reg based
>>>       on current verifier state
>>
>> +1
>>
>>>     * ref_convert_owning_non_owning - convert owning reference w/
>>>       specified ref_obj_id to non-owning references. Setup
>>>       non_owning_ref_lock for each reg with that ref_obj_id and 0 out
>>>       its ref_obj_id
>>
>> +1
>>
>>>   * New KF_RELEASE_NON_OWN flag is added, to be used in conjunction with
>>>     KF_RELEASE to indicate that the release arg reg should be converted
>>>     to non-owning ref
>>>     * Plain KF_RELEASE would clobber all regs with ref_obj_id matching
>>>       the release arg reg's. KF_RELEASE_NON_OWN's logic triggers first -
>>>       doing ref_convert_owning_non_owning on the ref first, which
>>>       prevents the regs from being clobbered by 0ing out their
>>>       ref_obj_ids. The bpf_reference_state itself is still released via
>>>       release_reference as a result of the KF_RELEASE flag.
>>>     * KF_RELEASE | KF_RELEASE_NON_OWN are added to
>>>       bpf_list_push_{front,back}
>>
>> And this bit is confusing and not generalizable.
> 
> +1 on both counts. If we want to make it generalizable, I think the only
> way to do would be to generalize it across different graph map types.
> For example, to have kfunc flags like KF_GRAPH_INSERT and
> KF_GRAPH_REMOVE which signal to the verifier that "for this graph-type
> map which has a spin-lock associated with its root node that I expect to
> be held, I've {inserted, removed} the node {to, from} the graph, so
> adjust the refcnt / pointer type accordingly and then clean up when the
> lock is dropped."
> 
> I don't see any reason to add kfunc flags for that though, as the fact
> that the pointer in question refers to a node that has a root node that
> has a lock associated with it is already itself a special-case scenario.
> I think we should just special-case these kfuncs in the verifier as
> "graph-type" kfuncs in some static global array(s).  That's probably
> less error prone anyways, and I don't see the typical kfunc writer ever
> needing to do this.
> 

re: "generalizable" and "why add a kfunc flag at all", I addressed that in
a side-reply to the msg which you're replying to here [0].

But to address your specific points:

"the fact that the pointer in question refers to a node that has a root node
that has a lock associated with it is already itself a special-case scenario"

Are you trying to say here that because the arg is of a special type, special
behavior should be tied to that arg type instead of the function? If so, that's
addressed in [0]. A function with KF_RELEASE_NON_OWN semantics certainly does
need args of a certain type in order to do its thing, but the semantic is really
a function-level thing. If we can tag the function with it, then later check arg
regs, that's preferable to checking kfunc id while processing arg regs, as the
latter conflates "the arg is of this special type so the function should do X"
with "the function does X so it must have an arg with this special type".

  [0]: https://lore.kernel.org/bpf/9763aed7-0284-e400-b4dc-ed01718d8e1e@meta.com/

>> As David noticed in his reply KF_RELEASE_NON_OWN is not a great name.
>> It's hard to come up with a good name and it won't be generic anyway.
>> The ref_convert_owning_non_owning has to be applied to a specific arg.
>> The function itself is not KF_RELEASE in the current definition of it.
>> The combination of KF_RELEASE|KF_RELEASE_NON_OWN is something new
>> that should have been generic, but doesn't really work this way.
>> In the next patches rbtree_root/node still has to have all the custom
>> logic.
>> KF_RELEASE_NON_OWN by itself is a nonsensical flag.
> 
> IMO if a flag doesn't make any sense on its own, or even possibly if it
> needs to be mutually exclusive with one or more other flags, it is
> probably never a correct building block. Even KF_TRUSTED_ARGS doesn't
> really make sense, as it's redundant if KF_RCU is specified. This is
> fine though, as IIUC our long-term plan is to get rid of KF_TRUSTED_ARGS
> and make it the default behavior for all kfuncs (not trying to hijack
> this thread with a tangential discussion about KF_TRUSTED_ARGS, just
> using this as an opportunity to point out something to keep in mind as
> we continue to add kfunc flags down the road).
> 

I'm fine with making KF_RELEASE_NON_OWN not depend on KF_RELEASE. Addressed in
[0] above.

>> Only combination of KF_RELEASE|KF_RELEASE_NON_OWN sort-of kinda makes
>> sense, but still hard to understand what releases what.
> 
> I agree and I think this is an important point. IMO it is a worse
> tradeoff to try to generalize this by complicating the definition of a
> reference than it is to keep the refcounting APIs straightforward and
> well defined. As a basic building block, having an owning refcount
> should mean one thing: that the object will not be destroyed and is safe
> to dereference. When you start mixing in these graph-specific notions of
> references meaning different things in specific contexts, it compromises
> that and makes the API significantly less usable and extensible.
> 

"Generalize" was the wrong word for me to use here. Addressed in [0] above.

Regarding polluting the meaning of "reference": owning and non-owning references
are intentionally scoped to graph datastructures only, and have well-defined and
documented meaning in that context. Elsewhere in the verifier "reference",
"owning refcount", etc are not well-defined as folks have been adding whatever
semantics they need to get their stuff working for some time. Scoping these
new concepts to graph datastructures only is my attempt at making progress
without adding to that confusion.

> For example, at some point we may decide to add something like a
> kptr_weak_ref which would function exactly like an std::weak_ptr, except
> of course that it would wrap a kptr_ref instead of an std::shared_ptr.
> IMO something like that is a more natural and generalizable building
> block that cleanly complements refcounting as it exists today.
> 

Any functionality that implements the desired semantics for rbtree / linked_list
is fine with me. If it's a superset of what I'm adding here, happy to migrate.

If changes to rbtree/linked_list APIs are needed to make such migration
possible, luckily it's all unstable kptr/kfunc, so that better future state
isn't blocked by these semantics / implementation.

All this next-gen datastructure work has been an exercise in YAGNI and scope
reduction. Luckily since it's all unstable API we're not backing ourselves
into any corners by doing so.

re "std::weak_ptr" idea more specifically - despite obvious similarities to
some rust or cpp concepts, I've been intentionally avoiding trying to sell this
work as such or copying semantics wholesale. Better to focus on the specific
things needed to move forward and avoid starting big-scope arguments like
"should we just add std::shared_ptr semantics?" "should the verifier be doing
'borrow checking' similar to rust, and if so to what extent". Don't get me
wrong, I'd find such discussions interesting, but a YAGNI approach where such
functionality is gradually added in response to concrete usecases will likely
save much contentious back-and-forth.

>> More below.
>>
>>> After these changes, linked_list's "release on unlock" logic continues
>>> to function as before, except for the semantic differences noted above.
>>> The patch immediately following this one makes minor changes to
>>> linked_list selftests to account for the differing behavior.
>>>
>>> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
>>> ---
>>>  include/linux/bpf.h          |   1 +
>>>  include/linux/bpf_verifier.h |  39 ++++-----
>>>  include/linux/btf.h          |  17 ++--
>>>  kernel/bpf/helpers.c         |   4 +-
>>>  kernel/bpf/verifier.c        | 164 ++++++++++++++++++++++++-----------
>>>  5 files changed, 146 insertions(+), 79 deletions(-)
>>>
>>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>>> index 3de24cfb7a3d..f71571bf6adc 100644
>>> --- a/include/linux/bpf.h
>>> +++ b/include/linux/bpf.h
>>> @@ -180,6 +180,7 @@ enum btf_field_type {
>>>  	BPF_KPTR       = BPF_KPTR_UNREF | BPF_KPTR_REF,
>>>  	BPF_LIST_HEAD  = (1 << 4),
>>>  	BPF_LIST_NODE  = (1 << 5),
>>> +	BPF_GRAPH_NODE_OR_ROOT = BPF_LIST_NODE | BPF_LIST_HEAD,
> 
> Can you update the rest of the elements here to keep common indentation?
> 

Ack

>>>  };
>>>  
>>>  struct btf_field_kptr {
>>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>>> index 53d175cbaa02..cb417ffbbb84 100644
>>> --- a/include/linux/bpf_verifier.h
>>> +++ b/include/linux/bpf_verifier.h
>>> @@ -43,6 +43,22 @@ enum bpf_reg_liveness {
>>>  	REG_LIVE_DONE = 0x8, /* liveness won't be updating this register anymore */
>>>  };
>>>  
>>> +/* For every reg representing a map value or allocated object pointer,
>>> + * we consider the tuple of (ptr, id) for them to be unique in verifier
>>> + * context and conside them to not alias each other for the purposes of
>>> + * tracking lock state.
>>> + */
>>> +struct bpf_active_lock {
>>> +	/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
>>> +	 * there's no active lock held, and other fields have no
>>> +	 * meaning. If non-NULL, it indicates that a lock is held and
>>> +	 * id member has the reg->id of the register which can be >= 0.
>>> +	 */
>>> +	void *ptr;
>>> +	/* This will be reg->id */
>>> +	u32 id;
>>> +};
>>> +
>>>  struct bpf_reg_state {
>>>  	/* Ordering of fields matters.  See states_equal() */
>>>  	enum bpf_reg_type type;
>>> @@ -68,6 +84,7 @@ struct bpf_reg_state {
>>>  		struct {
>>>  			struct btf *btf;
>>>  			u32 btf_id;
>>> +			struct bpf_active_lock non_owning_ref_lock;
>>
>> In your other email you argue that pointer should be enough.
>> I suspect that won't be correct.
>> See fixes that Andrii did in states_equal() and regsafe().
>> In particular:
>>         if (!!old->active_lock.id != !!cur->active_lock.id)
>>                 return false;
>>
>>         if (old->active_lock.id &&
>>             !check_ids(old->active_lock.id, cur->active_lock.id, env->idmap_scratch))
>>                 return false;
>>
>> We have to do the comparison of this new ID via idmap as well.
>>
>> I think introduction of struct bpf_active_lock  and addition of it
>> to bpf_reg_state is overkill.
>> Here we can add 'u32 non_own_ref_obj_id;' only and compare it via idmap in regsafe().
>> I'm guessing you didn't like my 'active_lock_id' suggestion. Fine.
>> non_own_ref_obj_id would match existing ref_obj_id at least.
>>
>>>  		};
>>>  
>>>  		u32 mem_size; /* for PTR_TO_MEM | PTR_TO_MEM_OR_NULL */
>>> @@ -223,11 +240,6 @@ struct bpf_reference_state {
>>>  	 * exiting a callback function.
>>>  	 */
>>>  	int callback_ref;
>>> -	/* Mark the reference state to release the registers sharing the same id
>>> -	 * on bpf_spin_unlock (for nodes that we will lose ownership to but are
>>> -	 * safe to access inside the critical section).
>>> -	 */
>>> -	bool release_on_unlock;
>>>  };
>>>  
>>>  /* state of the program:
>>> @@ -328,21 +340,8 @@ struct bpf_verifier_state {
>>>  	u32 branches;
>>>  	u32 insn_idx;
>>>  	u32 curframe;
>>> -	/* For every reg representing a map value or allocated object pointer,
>>> -	 * we consider the tuple of (ptr, id) for them to be unique in verifier
>>> -	 * context and conside them to not alias each other for the purposes of
>>> -	 * tracking lock state.
>>> -	 */
>>> -	struct {
>>> -		/* This can either be reg->map_ptr or reg->btf. If ptr is NULL,
>>> -		 * there's no active lock held, and other fields have no
>>> -		 * meaning. If non-NULL, it indicates that a lock is held and
>>> -		 * id member has the reg->id of the register which can be >= 0.
>>> -		 */
>>> -		void *ptr;
>>> -		/* This will be reg->id */
>>> -		u32 id;
>>> -	} active_lock;
>>
>> I would keep it as-is.
>>
>>> +
>>> +	struct bpf_active_lock active_lock;
>>>  	bool speculative;
>>>  	bool active_rcu_lock;
>>>  
>>> diff --git a/include/linux/btf.h b/include/linux/btf.h
>>> index 5f628f323442..8aee3f7f4248 100644
>>> --- a/include/linux/btf.h
>>> +++ b/include/linux/btf.h
>>> @@ -15,10 +15,10 @@
>>>  #define BTF_TYPE_EMIT_ENUM(enum_val) ((void)enum_val)
>>>  
>>>  /* These need to be macros, as the expressions are used in assembler input */
>>> -#define KF_ACQUIRE	(1 << 0) /* kfunc is an acquire function */
>>> -#define KF_RELEASE	(1 << 1) /* kfunc is a release function */
>>> -#define KF_RET_NULL	(1 << 2) /* kfunc returns a pointer that may be NULL */
>>> -#define KF_KPTR_GET	(1 << 3) /* kfunc returns reference to a kptr */
>>> +#define KF_ACQUIRE		(1 << 0) /* kfunc is an acquire function */
>>> +#define KF_RELEASE		(1 << 1) /* kfunc is a release function */
>>> +#define KF_RET_NULL		(1 << 2) /* kfunc returns a pointer that may be NULL */
>>> +#define KF_KPTR_GET		(1 << 3) /* kfunc returns reference to a kptr */
>>>  /* Trusted arguments are those which are guaranteed to be valid when passed to
>>>   * the kfunc. It is used to enforce that pointers obtained from either acquire
>>>   * kfuncs, or from the main kernel on a tracepoint or struct_ops callback
>>> @@ -67,10 +67,11 @@
>>>   *	return 0;
>>>   * }
>>>   */
>>> -#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */
>>> -#define KF_SLEEPABLE    (1 << 5) /* kfunc may sleep */
>>> -#define KF_DESTRUCTIVE  (1 << 6) /* kfunc performs destructive actions */
>>> -#define KF_RCU          (1 << 7) /* kfunc only takes rcu pointer arguments */
>>> +#define KF_TRUSTED_ARGS	(1 << 4) /* kfunc only takes trusted pointer arguments */
>>> +#define KF_SLEEPABLE		(1 << 5) /* kfunc may sleep */
>>> +#define KF_DESTRUCTIVE		(1 << 6) /* kfunc performs destructive actions */
>>> +#define KF_RCU			(1 << 7) /* kfunc only takes rcu pointer arguments */
>>> +#define KF_RELEASE_NON_OWN	(1 << 8) /* kfunc converts its referenced arg into non-owning ref */
>>
>> No need for this flag.
>>
>>>  /*
>>>   * Return the name of the passed struct, if exists, or halt the build if for
>>> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
>>> index af30c6cbd65d..e041409779c3 100644
>>> --- a/kernel/bpf/helpers.c
>>> +++ b/kernel/bpf/helpers.c
>>> @@ -2049,8 +2049,8 @@ BTF_ID_FLAGS(func, crash_kexec, KF_DESTRUCTIVE)
>>>  #endif
>>>  BTF_ID_FLAGS(func, bpf_obj_new_impl, KF_ACQUIRE | KF_RET_NULL)
>>>  BTF_ID_FLAGS(func, bpf_obj_drop_impl, KF_RELEASE)
>>> -BTF_ID_FLAGS(func, bpf_list_push_front)
>>> -BTF_ID_FLAGS(func, bpf_list_push_back)
>>> +BTF_ID_FLAGS(func, bpf_list_push_front, KF_RELEASE | KF_RELEASE_NON_OWN)
>>> +BTF_ID_FLAGS(func, bpf_list_push_back, KF_RELEASE | KF_RELEASE_NON_OWN)
>>
>> No need for this.
>>
>>>  BTF_ID_FLAGS(func, bpf_list_pop_front, KF_ACQUIRE | KF_RET_NULL)
>>>  BTF_ID_FLAGS(func, bpf_list_pop_back, KF_ACQUIRE | KF_RET_NULL)
>>>  BTF_ID_FLAGS(func, bpf_task_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index 824e2242eae5..84b0660e2a76 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -190,6 +190,10 @@ struct bpf_verifier_stack_elem {
>>>  
>>>  static int acquire_reference_state(struct bpf_verifier_env *env, int insn_idx);
>>>  static int release_reference(struct bpf_verifier_env *env, int ref_obj_id);
>>> +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
>>> +				       struct bpf_active_lock *lock);
>>> +static int ref_set_non_owning_lock(struct bpf_verifier_env *env,
>>> +				   struct bpf_reg_state *reg);
>>>  
>>>  static bool bpf_map_ptr_poisoned(const struct bpf_insn_aux_data *aux)
>>>  {
>>> @@ -931,6 +935,9 @@ static void print_verifier_state(struct bpf_verifier_env *env,
>>>  				verbose_a("id=%d", reg->id);
>>>  			if (reg->ref_obj_id)
>>>  				verbose_a("ref_obj_id=%d", reg->ref_obj_id);
>>> +			if (reg->non_owning_ref_lock.ptr)
>>> +				verbose_a("non_own_id=(%p,%d)", reg->non_owning_ref_lock.ptr,
>>> +					  reg->non_owning_ref_lock.id);
>>>  			if (t != SCALAR_VALUE)
>>>  				verbose_a("off=%d", reg->off);
>>>  			if (type_is_pkt_pointer(t))
>>> @@ -4820,7 +4827,8 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
>>>  			return -EACCES;
>>>  		}
>>>  
>>> -		if (type_is_alloc(reg->type) && !reg->ref_obj_id) {
>>> +		if (type_is_alloc(reg->type) && !reg->ref_obj_id &&
>>> +		    !reg->non_owning_ref_lock.ptr) {
>>>  			verbose(env, "verifier internal error: ref_obj_id for allocated object must be non-zero\n");
>>>  			return -EFAULT;
>>>  		}
>>> @@ -5778,9 +5786,7 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
>>>  			cur->active_lock.ptr = btf;
>>>  		cur->active_lock.id = reg->id;
>>>  	} else {
>>> -		struct bpf_func_state *fstate = cur_func(env);
>>>  		void *ptr;
>>> -		int i;
>>>  
>>>  		if (map)
>>>  			ptr = map;
>>> @@ -5796,25 +5802,11 @@ static int process_spin_lock(struct bpf_verifier_env *env, int regno,
>>>  			verbose(env, "bpf_spin_unlock of different lock\n");
>>>  			return -EINVAL;
>>>  		}
>>> -		cur->active_lock.ptr = NULL;
>>> -		cur->active_lock.id = 0;
>>>  
>>> -		for (i = fstate->acquired_refs - 1; i >= 0; i--) {
>>> -			int err;
>>> +		invalidate_non_owning_refs(env, &cur->active_lock);
>>
>> +1
>>
>>> -			/* Complain on error because this reference state cannot
>>> -			 * be freed before this point, as bpf_spin_lock critical
>>> -			 * section does not allow functions that release the
>>> -			 * allocated object immediately.
>>> -			 */
>>> -			if (!fstate->refs[i].release_on_unlock)
>>> -				continue;
>>> -			err = release_reference(env, fstate->refs[i].id);
>>> -			if (err) {
>>> -				verbose(env, "failed to release release_on_unlock reference");
>>> -				return err;
>>> -			}
>>> -		}
>>> +		cur->active_lock.ptr = NULL;
>>> +		cur->active_lock.id = 0;
>>
>> +1
>>
>>>  	}
>>>  	return 0;
>>>  }
>>> @@ -6273,6 +6265,23 @@ static int check_reg_type(struct bpf_verifier_env *env, u32 regno,
>>>  	return 0;
>>>  }
>>>  
>>> +static struct btf_field *
>>> +reg_find_field_offset(const struct bpf_reg_state *reg, s32 off, u32 fields)
>>> +{
>>> +	struct btf_field *field;
>>> +	struct btf_record *rec;
>>> +
>>> +	rec = reg_btf_record(reg);
>>> +	if (!reg)
>>> +		return NULL;
>>> +
>>> +	field = btf_record_find(rec, off, fields);
>>> +	if (!field)
>>> +		return NULL;
>>> +
>>> +	return field;
>>> +}
>>
>> Doesn't look like that this helper is really necessary.
>>
>>> +
>>>  int check_func_arg_reg_off(struct bpf_verifier_env *env,
>>>  			   const struct bpf_reg_state *reg, int regno,
>>>  			   enum bpf_arg_type arg_type)
>>> @@ -6294,6 +6303,18 @@ int check_func_arg_reg_off(struct bpf_verifier_env *env,
>>>  		 */
>>>  		if (arg_type_is_dynptr(arg_type) && type == PTR_TO_STACK)
>>>  			return 0;
>>> +
>>> +		if (type == (PTR_TO_BTF_ID | MEM_ALLOC) && reg->off) {
>>> +			if (reg_find_field_offset(reg, reg->off, BPF_GRAPH_NODE_OR_ROOT))
>>> +				return __check_ptr_off_reg(env, reg, regno, true);
>>> +
>>> +			verbose(env, "R%d must have zero offset when passed to release func\n",
>>> +				regno);
>>> +			verbose(env, "No graph node or root found at R%d type:%s off:%d\n", regno,
>>> +				kernel_type_name(reg->btf, reg->btf_id), reg->off);
>>> +			return -EINVAL;
>>> +		}
>>
>> This bit is only necessary if we mark push_list as KF_RELEASE.
>> Just don't add this mark and drop above.
>>
>>> +
>>>  		/* Doing check_ptr_off_reg check for the offset will catch this
>>>  		 * because fixed_off_ok is false, but checking here allows us
>>>  		 * to give the user a better error message.
>>> @@ -7055,6 +7076,20 @@ static int release_reference(struct bpf_verifier_env *env,
>>>  	return 0;
>>>  }
>>>  
>>> +static void invalidate_non_owning_refs(struct bpf_verifier_env *env,
>>> +				       struct bpf_active_lock *lock)
>>> +{
>>> +	struct bpf_func_state *unused;
>>> +	struct bpf_reg_state *reg;
>>> +
>>> +	bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
>>> +		if (reg->non_owning_ref_lock.ptr &&
>>> +		    reg->non_owning_ref_lock.ptr == lock->ptr &&
>>> +		    reg->non_owning_ref_lock.id == lock->id)
>>
>> I think the lock.ptr = lock->ptr comparison is unnecessary to invalidate things.
>> We're under active spin_lock here. All regs were checked earlier and id keeps incrementing.
>> So we can just do 'u32 non_own_ref_obj_id'.
>>
>>> +			__mark_reg_unknown(env, reg);
>>> +	}));
>>> +}
>>> +
>>>  static void clear_caller_saved_regs(struct bpf_verifier_env *env,
>>>  				    struct bpf_reg_state *regs)
>>>  {
>>> @@ -8266,6 +8301,11 @@ static bool is_kfunc_release(struct bpf_kfunc_call_arg_meta *meta)
>>>  	return meta->kfunc_flags & KF_RELEASE;
>>>  }
>>>  
>>> +static bool is_kfunc_release_non_own(struct bpf_kfunc_call_arg_meta *meta)
>>> +{
>>> +	return meta->kfunc_flags & KF_RELEASE_NON_OWN;
>>> +}
>>> +
>>
>> No need.
>>
>>>  static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
>>>  {
>>>  	return meta->kfunc_flags & KF_TRUSTED_ARGS;
>>> @@ -8651,38 +8691,55 @@ static int process_kf_arg_ptr_to_kptr(struct bpf_verifier_env *env,
>>>  	return 0;
>>>  }
>>>  
>>> -static int ref_set_release_on_unlock(struct bpf_verifier_env *env, u32 ref_obj_id)
>>> +static int ref_set_non_owning_lock(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
>>>  {
>>> -	struct bpf_func_state *state = cur_func(env);
>>> +	struct bpf_verifier_state *state = env->cur_state;
>>> +
>>> +	if (!state->active_lock.ptr) {
>>> +		verbose(env, "verifier internal error: ref_set_non_owning_lock w/o active lock\n");
>>> +		return -EFAULT;
>>> +	}
>>> +
>>> +	if (reg->non_owning_ref_lock.ptr) {
>>> +		verbose(env, "verifier internal error: non_owning_ref_lock already set\n");
>>> +		return -EFAULT;
>>> +	}
>>> +
>>> +	reg->non_owning_ref_lock.id = state->active_lock.id;
>>> +	reg->non_owning_ref_lock.ptr = state->active_lock.ptr;
>>> +	return 0;
>>> +}
>>> +
>>> +static int ref_convert_owning_non_owning(struct bpf_verifier_env *env, u32 ref_obj_id)
>>> +{
>>> +	struct bpf_func_state *state, *unused;
>>>  	struct bpf_reg_state *reg;
>>>  	int i;
>>>  
>>> -	/* bpf_spin_lock only allows calling list_push and list_pop, no BPF
>>> -	 * subprogs, no global functions. This means that the references would
>>> -	 * not be released inside the critical section but they may be added to
>>> -	 * the reference state, and the acquired_refs are never copied out for a
>>> -	 * different frame as BPF to BPF calls don't work in bpf_spin_lock
>>> -	 * critical sections.
>>> -	 */
>>> +	state = cur_func(env);
>>> +
>>>  	if (!ref_obj_id) {
>>> -		verbose(env, "verifier internal error: ref_obj_id is zero for release_on_unlock\n");
>>> +		verbose(env, "verifier internal error: ref_obj_id is zero for "
>>> +			     "owning -> non-owning conversion\n");
>>>  		return -EFAULT;
>>>  	}
>>> +
>>>  	for (i = 0; i < state->acquired_refs; i++) {
>>> -		if (state->refs[i].id == ref_obj_id) {
>>> -			if (state->refs[i].release_on_unlock) {
>>> -				verbose(env, "verifier internal error: expected false release_on_unlock");
>>> -				return -EFAULT;
>>> +		if (state->refs[i].id != ref_obj_id)
>>> +			continue;
>>> +
>>> +		/* Clear ref_obj_id here so release_reference doesn't clobber
>>> +		 * the whole reg
>>> +		 */
>>> +		bpf_for_each_reg_in_vstate(env->cur_state, unused, reg, ({
>>> +			if (reg->ref_obj_id == ref_obj_id) {
>>> +				reg->ref_obj_id = 0;
>>> +				ref_set_non_owning_lock(env, reg);
>>
>> +1 except ref_set_... name doesn't quite fit. reg_set_... is more accurate, no?
>> and probably reg_set_non_own_ref_obj_id() ?
>> Or just open code it?
>>
>>>  			}
>>> -			state->refs[i].release_on_unlock = true;
>>> -			/* Now mark everyone sharing same ref_obj_id as untrusted */
>>> -			bpf_for_each_reg_in_vstate(env->cur_state, state, reg, ({
>>> -				if (reg->ref_obj_id == ref_obj_id)
>>> -					reg->type |= PTR_UNTRUSTED;
>>> -			}));
>>> -			return 0;
>>> -		}
>>> +		}));
>>> +		return 0;
>>>  	}
>>> +
>>>  	verbose(env, "verifier internal error: ref state missing for ref_obj_id\n");
>>>  	return -EFAULT;
>>>  }
>>> @@ -8817,7 +8874,6 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>>>  {
>>>  	const struct btf_type *et, *t;
>>>  	struct btf_field *field;
>>> -	struct btf_record *rec;
>>>  	u32 list_node_off;
>>>  
>>>  	if (meta->btf != btf_vmlinux ||
>>> @@ -8834,9 +8890,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>>>  		return -EINVAL;
>>>  	}
>>>  
>>> -	rec = reg_btf_record(reg);
>>>  	list_node_off = reg->off + reg->var_off.value;
>>> -	field = btf_record_find(rec, list_node_off, BPF_LIST_NODE);
>>> +	field = reg_find_field_offset(reg, list_node_off, BPF_LIST_NODE);
>>>  	if (!field || field->offset != list_node_off) {
>>>  		verbose(env, "bpf_list_node not found at offset=%u\n", list_node_off);
>>>  		return -EINVAL;
>>> @@ -8861,8 +8916,8 @@ static int process_kf_arg_ptr_to_list_node(struct bpf_verifier_env *env,
>>>  			btf_name_by_offset(field->list_head.btf, et->name_off));
>>>  		return -EINVAL;
>>>  	}
>>> -	/* Set arg#1 for expiration after unlock */
>>> -	return ref_set_release_on_unlock(env, reg->ref_obj_id);
>>> +
>>> +	return 0;
>>
>> and here we come to the main point.
>> Can you just call
>> ref_convert_owning_non_owning(env, reg->ref_obj_id) and release_reference() here?
>> Everything will be so much simpler, no?
>>
>>>  }
>>>  
>>>  static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_arg_meta *meta)
>>> @@ -9132,11 +9187,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>>  			    int *insn_idx_p)
>>>  {
>>>  	const struct btf_type *t, *func, *func_proto, *ptr_type;
>>> +	u32 i, nargs, func_id, ptr_type_id, release_ref_obj_id;
>>>  	struct bpf_reg_state *regs = cur_regs(env);
>>>  	const char *func_name, *ptr_type_name;
>>>  	bool sleepable, rcu_lock, rcu_unlock;
>>>  	struct bpf_kfunc_call_arg_meta meta;
>>> -	u32 i, nargs, func_id, ptr_type_id;
>>>  	int err, insn_idx = *insn_idx_p;
>>>  	const struct btf_param *args;
>>>  	const struct btf_type *ret_t;
>>> @@ -9223,7 +9278,18 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>>>  	 * PTR_TO_BTF_ID in bpf_kfunc_arg_meta, do the release now.
>>>  	 */
>>>  	if (meta.release_regno) {
>>> -		err = release_reference(env, regs[meta.release_regno].ref_obj_id);
>>> +		err = 0;
>>> +		release_ref_obj_id = regs[meta.release_regno].ref_obj_id;
>>> +
>>> +		if (is_kfunc_release_non_own(&meta))
>>> +			err = ref_convert_owning_non_owning(env, release_ref_obj_id);
>>> +		if (err) {
>>> +			verbose(env, "kfunc %s#%d conversion of owning ref to non-owning failed\n",
>>> +				func_name, func_id);
>>> +			return err;
>>> +		}
>>> +
>>> +		err = release_reference(env, release_ref_obj_id);
>>
>> and this bit won't be needed.
>> and no need to guess in patch 1 which arg has to be released and converted to non_own.
>>
>>>  		if (err) {
>>>  			verbose(env, "kfunc %s#%d reference has not been acquired before\n",
>>>  				func_name, func_id);
>>> -- 
>>> 2.30.2
>>>

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics
  2023-01-17 16:07     ` Dave Marchevsky
@ 2023-01-17 16:56       ` Alexei Starovoitov
  0 siblings, 0 replies; 37+ messages in thread
From: Alexei Starovoitov @ 2023-01-17 16:56 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Tue, Jan 17, 2023 at 8:07 AM Dave Marchevsky <davemarchevsky@meta.com> wrote:
>
> How about I try to make the names better in v3 instead of removing the kfunc
> flags entirely? If you're still opposed after that, I will instead add helpers
> with comments like:

Please review what I did with this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20221230010738.45277-1-alexei.starovoitov@gmail.com/

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2022-12-29 17:00       ` David Vernet
@ 2023-01-17 17:26         ` Dave Marchevsky
  2023-01-17 17:36           ` Alexei Starovoitov
  2023-01-20  5:13           ` David Vernet
  0 siblings, 2 replies; 37+ messages in thread
From: Dave Marchevsky @ 2023-01-17 17:26 UTC (permalink / raw)
  To: David Vernet, Alexei Starovoitov
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On 12/29/22 12:00 PM, David Vernet wrote:
> On Thu, Dec 29, 2022 at 08:50:19AM -0800, Alexei Starovoitov wrote:
>> On Wed, Dec 28, 2022 at 10:40 PM David Vernet <void@manifault.com> wrote:
>>>
>>> On Sat, Dec 17, 2022 at 12:24:54AM -0800, Dave Marchevsky wrote:
>>>> Currently, kfuncs marked KF_RELEASE indicate that they release some
>>>> previously-acquired arg. The verifier assumes that such a function will
>>>> only have one arg reg w/ ref_obj_id set, and that that arg is the one to
>>>> be released. Multiple kfunc arg regs have ref_obj_id set is considered
>>>> an invalid state.
>>>>
>>>> For helpers, RELEASE is used to tag a particular arg in the function
>>>> proto, not the function itself. The arg with OBJ_RELEASE type tag is the
>>>> arg that the helper will release. There can only be one such tagged arg.
>>>> When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
>>>> also considered an invalid state.
>>>>
>>>> Later patches in this series will result in some linked_list helpers
>>>> marked KF_RELEASE having a valid reason to take two ref_obj_id args.
>>>> Specifically, bpf_list_push_{front,back} can push a node to a list head
>>>> which is itself part of a list node. In such a scenario both arguments
>>>> to these functions would have ref_obj_id > 0, thus would fail
>>>> verification under current logic.
>>>>
>>>> This patch changes kfunc ref_obj_id searching logic to find the last arg
>>>> reg w/ ref_obj_id and consider that the reg-to-release. This should be
>>>> backwards-compatible with all current kfuncs as they only expect one
>>>> such arg reg.
>>>
>>> Can't say I'm a huge fan of this proposal :-( While I think it's really
>>> unfortunate that kfunc flags are not defined per-arg for this exact type
>>> of reason, adding more flag-specific semantics like this is IMO a step
>>> in the wrong direction.  It's similar to the existing __sz and __k
>>> argument-naming semantics that inform the verifier that the arguments
>>> have special meaning. All of these little additions of special-case
>>> handling for kfunc flags end up requiring people writing kfuncs (and
>>> sometimes calling them) to read through the verifier to understand
>>> what's going on (though I will say that it's nice that __sz and __k are
>>> properly documented in [0]).
>>
>> Before getting to pros/cons of KF_* vs name suffix vs helper style
>> per-arg description...
>> It's important to highlight that here we're talking about
>> link list and rb tree kfuncs that are not like other kfuncs.
>> Majority of kfuncs can be added by subsystems like hid-bpf
>> without touching the verifier.
> 
> I hear you and I agree. It wasn't my intention to drag us into a larger
> discussion about kfuncs vs. helpers, but rather just to point out that I
> think we have to try hard to avoid adding special-case logic that
> requires looking into the verifier to understand the semantics. I think
> we're on the same page about this, based on this and your other
> response.
> 

In another thread you also mentioned that hypothetical "kfunc writer" persona
shouldn't have to understand kfunc flags in order to add their simple kfunc, and
I think your comments here are also presupposing a "kfunc writer" persona that
doesn't look at the verifier. Having such a person able to add kfuncs without
understanding the verifier is a good goal, but doesn't reflect current
reality when the kfunc needs to have any special semantics.

Regardless, I'd expect that anyone adding further new-style Graph
datastructures, old-style maps, or new datastructures unrelated to either,
will be closer to "verifier expert" than "random person adding a few kfuncs".

>> Here we're paving the way for graph (aka new gen data structs)
>> and so far not only kfuncs, but their arg types have to have
>> special handling inside the verifier.
>> There is not much yet to generalize and expose as generic KF_
>> flag or as a name suffix.
>> Therefore I think it's more appropriate to implement them
>> with minimal verifier changes and minimal complexity.
> 
> Agreed
> 

'Generalize' was addressed in Patch 2's thread.

>> There is no 3rd graph algorithm on the horizon after link list
>> and rbtree. Instead there is a big todo list for
>> 'multi owner graph node' and 'bpf_refcount_t'.
> 
> In this case my point in [0] of the only option for generalizing being
> to have something like KF_GRAPH_INSERT / KF_GRAPH_REMOVE is just not the
> way forward (which I also said was my opinion when I pointed it out as
> an option). Let's just special-case these kfuncs. There's already a
> precedence for doing that in the verifier anyways. Minimal complexity,
> minimal API changes. It's a win-win.
> 
> [0]: https://lore.kernel.org/all/Y63GLqZil9l1NzY4@maniforge.lan/
> 

There's certainly precedent for adding special-case "kfunc_id == KFUNC_whatever"
all over the verifier. It's a bad precedent, though, for reasons discussed in
[0].

To specifically address your points here, I don't buy the argument that
special-casing based on func id is "minimal complexity, minimal API changes".
Re: 'complexity': the logic implementing the complicated semantic will be
added regardless, it just won't have a name that's easily referenced in docs
and mailing list discussions.

Similarly, re: 'API changes': if by 'API' here you mean "API that's exposed
to folks adding kfuncs" - see my comments about "kfunc writer" persona above.
We can think of the verifier itself as an API too - with a single bpf_check
function. That API's behavior is indeed changed here, regardless of whether
the added semantics are gated by a kfunc flag or special-case checks. I don't
think that hiding complexity behind special-case checks when there could be
a named flag simplifies anything. The complexity is added regardless, question
is how many breadcrumbs and pointers we want to leave for folks trying to make
sense of it in the future.

  [0]: https://lore.kernel.org/bpf/9763aed7-0284-e400-b4dc-ed01718d8e1e@meta.com/

>> Those will require bigger changes in the verifier,
>> so I'd like to avoid premature generalization :) as analogous
>> to premature optimization :)
> 
> And of course given my points above and in other threads: agreed. I
> think we have an ideal middle-ground for minimizing complexity in the
> short term, and some nice follow-on todo-list items to work on in the
> medium-long term which will continue to improve things without
> (negatively) affecting users in any way. All SGTM

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2023-01-17 17:26         ` Dave Marchevsky
@ 2023-01-17 17:36           ` Alexei Starovoitov
  2023-01-17 23:12             ` Dave Marchevsky
  2023-01-20  5:13           ` David Vernet
  1 sibling, 1 reply; 37+ messages in thread
From: Alexei Starovoitov @ 2023-01-17 17:36 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: David Vernet, Dave Marchevsky, bpf, Alexei Starovoitov,
	Daniel Borkmann, Andrii Nakryiko, Kernel Team,
	Kumar Kartikeya Dwivedi, Tejun Heo

On Tue, Jan 17, 2023 at 9:26 AM Dave Marchevsky <davemarchevsky@meta.com> wrote:
>
> In another thread you also mentioned that hypothetical "kfunc writer" persona
> shouldn't have to understand kfunc flags in order to add their simple kfunc, and
> I think your comments here are also presupposing a "kfunc writer" persona that
> doesn't look at the verifier. Having such a person able to add kfuncs without
> understanding the verifier is a good goal, but doesn't reflect current
> reality when the kfunc needs to have any special semantics.

agree on that goal.

> Regardless, I'd expect that anyone adding further new-style Graph
> datastructures, old-style maps, or new datastructures unrelated to either,
> will be closer to "verifier expert" than "random person adding a few kfuncs".

also agree, since it's a reality right now.

> >> Here we're paving the way for graph (aka new gen data structs)
> >> and so far not only kfuncs, but their arg types have to have
> >> special handling inside the verifier.
> >> There is not much yet to generalize and expose as generic KF_
> >> flag or as a name suffix.
> >> Therefore I think it's more appropriate to implement them
> >> with minimal verifier changes and minimal complexity.
> >
> > Agreed
> >
>
> 'Generalize' was addressed in Patch 2's thread.
>
> >> There is no 3rd graph algorithm on the horizon after link list
> >> and rbtree. Instead there is a big todo list for
> >> 'multi owner graph node' and 'bpf_refcount_t'.
> >
> > In this case my point in [0] of the only option for generalizing being
> > to have something like KF_GRAPH_INSERT / KF_GRAPH_REMOVE is just not the
> > way forward (which I also said was my opinion when I pointed it out as
> > an option). Let's just special-case these kfuncs. There's already a
> > precedence for doing that in the verifier anyways. Minimal complexity,
> > minimal API changes. It's a win-win.
> >
> > [0]: https://lore.kernel.org/all/Y63GLqZil9l1NzY4@maniforge.lan/
> >
>
> There's certainly precedent for adding special-case "kfunc_id == KFUNC_whatever"
> all over the verifier. It's a bad precedent, though, for reasons discussed in
> [0].
>
> To specifically address your points here, I don't buy the argument that
> special-casing based on func id is "minimal complexity, minimal API changes".
> Re: 'complexity': the logic implementing the complicated semantic will be
> added regardless, it just won't have a name that's easily referenced in docs
> and mailing list discussions.
>
> Similarly, re: 'API changes': if by 'API' here you mean "API that's exposed
> to folks adding kfuncs" - see my comments about "kfunc writer" persona above.
> We can think of the verifier itself as an API too - with a single bpf_check
> function. That API's behavior is indeed changed here, regardless of whether
> the added semantics are gated by a kfunc flag or special-case checks. I don't
> think that hiding complexity behind special-case checks when there could be
> a named flag simplifies anything. The complexity is added regardless, question
> is how many breadcrumbs and pointers we want to leave for folks trying to make
> sense of it in the future.
>
>   [0]: https://lore.kernel.org/bpf/9763aed7-0284-e400-b4dc-ed01718d8e1e@meta.com/

I could have agreed to this as well if I didn't go and remove
all the new KF_*OWN* flags.
imo the resulting diff of mine vs your initial patch is easier to
follow and reason about.
So for this case "kfunc_id == KFUNC_whatever" is cleaner.
It doesn't mean that it will be the case in other situations.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2023-01-17 17:36           ` Alexei Starovoitov
@ 2023-01-17 23:12             ` Dave Marchevsky
  0 siblings, 0 replies; 37+ messages in thread
From: Dave Marchevsky @ 2023-01-17 23:12 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: David Vernet, Dave Marchevsky, bpf, Alexei Starovoitov,
	Daniel Borkmann, Andrii Nakryiko, Kernel Team,
	Kumar Kartikeya Dwivedi, Tejun Heo

On 1/17/23 12:36 PM, Alexei Starovoitov wrote:
> On Tue, Jan 17, 2023 at 9:26 AM Dave Marchevsky <davemarchevsky@meta.com> wrote:
>>
>> In another thread you also mentioned that hypothetical "kfunc writer" persona
>> shouldn't have to understand kfunc flags in order to add their simple kfunc, and
>> I think your comments here are also presupposing a "kfunc writer" persona that
>> doesn't look at the verifier. Having such a person able to add kfuncs without
>> understanding the verifier is a good goal, but doesn't reflect current
>> reality when the kfunc needs to have any special semantics.
> 
> agree on that goal.
> 
>> Regardless, I'd expect that anyone adding further new-style Graph
>> datastructures, old-style maps, or new datastructures unrelated to either,
>> will be closer to "verifier expert" than "random person adding a few kfuncs".
> 
> also agree, since it's a reality right now.
> 
>>>> Here we're paving the way for graph (aka new gen data structs)
>>>> and so far not only kfuncs, but their arg types have to have
>>>> special handling inside the verifier.
>>>> There is not much yet to generalize and expose as generic KF_
>>>> flag or as a name suffix.
>>>> Therefore I think it's more appropriate to implement them
>>>> with minimal verifier changes and minimal complexity.
>>>
>>> Agreed
>>>
>>
>> 'Generalize' was addressed in Patch 2's thread.
>>
>>>> There is no 3rd graph algorithm on the horizon after link list
>>>> and rbtree. Instead there is a big todo list for
>>>> 'multi owner graph node' and 'bpf_refcount_t'.
>>>
>>> In this case my point in [0] of the only option for generalizing being
>>> to have something like KF_GRAPH_INSERT / KF_GRAPH_REMOVE is just not the
>>> way forward (which I also said was my opinion when I pointed it out as
>>> an option). Let's just special-case these kfuncs. There's already a
>>> precedence for doing that in the verifier anyways. Minimal complexity,
>>> minimal API changes. It's a win-win.
>>>
>>> [0]: https://lore.kernel.org/all/Y63GLqZil9l1NzY4@maniforge.lan/
>>>
>>
>> There's certainly precedent for adding special-case "kfunc_id == KFUNC_whatever"
>> all over the verifier. It's a bad precedent, though, for reasons discussed in
>> [0].
>>
>> To specifically address your points here, I don't buy the argument that
>> special-casing based on func id is "minimal complexity, minimal API changes".
>> Re: 'complexity': the logic implementing the complicated semantic will be
>> added regardless, it just won't have a name that's easily referenced in docs
>> and mailing list discussions.
>>
>> Similarly, re: 'API changes': if by 'API' here you mean "API that's exposed
>> to folks adding kfuncs" - see my comments about "kfunc writer" persona above.
>> We can think of the verifier itself as an API too - with a single bpf_check
>> function. That API's behavior is indeed changed here, regardless of whether
>> the added semantics are gated by a kfunc flag or special-case checks. I don't
>> think that hiding complexity behind special-case checks when there could be
>> a named flag simplifies anything. The complexity is added regardless, question
>> is how many breadcrumbs and pointers we want to leave for folks trying to make
>> sense of it in the future.
>>
>>   [0]: https://lore.kernel.org/bpf/9763aed7-0284-e400-b4dc-ed01718d8e1e@meta.com/
> 
> I could have agreed to this as well if I didn't go and remove
> all the new KF_*OWN* flags.
> imo the resulting diff of mine vs your initial patch is easier to
> follow and reason about.
> So for this case "kfunc_id == KFUNC_whatever" is cleaner.
> It doesn't mean that it will be the case in other situations.

In the alternate "bpf: Migrate release_on_unlock logic to non-owning ref
semantics" series you submitted, you mean?

It's certainly a smaller diff and easier to reason about as an individual
change. IMO "smaller diff" is largely due to my version moving
convert_owning_non_owning semantics to function-level while yours keeps it at
arg-level. I think moving to function-level is necessary, elaborated on
why in the other deep side-thread [0].

  [0]: https://lore.kernel.org/bpf/9763aed7-0284-e400-b4dc-ed01718d8e1e@meta.com/

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs
  2022-12-28 21:26   ` David Vernet
@ 2023-01-18  2:16     ` Dave Marchevsky
  2023-01-20  4:45       ` David Vernet
  0 siblings, 1 reply; 37+ messages in thread
From: Dave Marchevsky @ 2023-01-18  2:16 UTC (permalink / raw)
  To: David Vernet, Dave Marchevsky
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On 12/28/22 4:26 PM, David Vernet wrote:
> On Sat, Dec 17, 2022 at 12:25:06AM -0800, Dave Marchevsky wrote:
>> It is difficult to intuit the semantics of owning and non-owning
>> references from verifier code. In order to keep the high-level details
>> from being lost in the mailing list, this patch adds documentation
>> explaining semantics and details.
>>
>> The target audience of doc added in this patch is folks working on BPF
>> internals, as there's focus on "what should the verifier do here". Via
>> reorganization or copy-and-paste, much of the content can probably be
>> repurposed for BPF program writer audience as well.
>>
>> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> 
> Hey Dave,
> 
> Thanks for writing this up. I left a few comments and suggestions as a
> first pass. Feel free to push back on any of them.
> 
>> ---
>>  Documentation/bpf/graph_ds_impl.rst | 208 ++++++++++++++++++++++++++++
>>  Documentation/bpf/other.rst         |   3 +-
>>  2 files changed, 210 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/bpf/graph_ds_impl.rst
>>
>> diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
>> new file mode 100644
>> index 000000000000..f92cbd223dc3
>> --- /dev/null
>> +++ b/Documentation/bpf/graph_ds_impl.rst
>> @@ -0,0 +1,208 @@
>> +=========================
>> +BPF Graph Data Structures
>> +=========================
>> +
>> +This document describes implementation details of new-style "graph" data
>> +structures (linked_list, rbtree), with particular focus on verifier
> 
> s/with particular/with a particular
> 

I'm no grammar expert, but based on my googling
"with particular focus" is widely used in newspapers and other places
where grammarians lurk.

>> +implementation of semantics particular to those data structures.
> 
> s/particular/specific
> 
> Just because we already use the word "particular" in the sentence?
> 

Ack

> In general this sentence feels a bit difficult to parse. Wdyt about
> this?
> 
> ...with a particular focus on how the verifier ensures that they are
> properly and safely used by BPF programs.
> 

Agreed in general, but re: your specific suggestion: "the verifier's
implementation of semantics specific to those data structures" communicates
that there are semantics specific to those data structures which required
verifier changes. 

"ensures that they are properly and safely used by BPF programs" is more
vague, but definitely easier to parse.

Will rewrite in some other way which is hopefully best of both worlds.

>> +
>> +Note that the intent of this document is to describe the current state of
>> +these graph data structures, **no guarantees** of stability for either
> 
> I think we can end the sentence in the middle here.
> 
> ...these graph data structures. **No guarantees**...

Ack

> 
> Should we also add a sentence or two here about the intended audience
> (people working on the verifier or readers who are interested in
> learning more about BPF internals)?
> 

Ack

>> +semantics or APIs are made or implied here.
>> +
>> +.. contents::
>> +    :local:
>> +    :depth: 2
>> +
>> +Introduction
>> +------------
>> +
>> +The BPF map API has historically been the main way to expose data structures
>> +of various types for use within BPF programs. Some data structures fit naturally
>> +with the map API (HASH, ARRAY), others less so. Consequentially, programs
> 
> Would you mind please adding some details on why some data structures
> don't fit naturally into the existing map APIs? I feel like that's kind
> of the main focus of the article, so it would probably help to give some
> high-level context up front.
> 
>> +interacting with the latter group of data structures can be hard to parse
>> +for kernel programmers without previous BPF experience.
> 
> I'm not sure I quite follow how this latter point about data structures
> being hard to parse is derived from the point about how some data
> structures don't fit naturally with the map APIs. Maybe we should say
> something like:
> 
> ..., others less so. Given that the API surface and behavioral semantics
> are fundmentally different between these two classes of BPF data
> structures, kernel programmers who are used to interacting with map-type
> data structures may find these graph-type data structures to be
> confusing or unfamiliar.
> 
> Wdyt?
> 

The "Introduction" section is trying to make these points:

  * Data structures have historically been forced to adhere to the Map API
  * Some data structures (linked list, rbtree) don't fit the Map API well
  * For data stuctures that don't fit the Map API well, two problems would
    arise if they were exposed as maps:
    * "square peg / round hole" - in a vacuum, it'd be hard to make sense
      of how Map API manipulates those data structures
    * "Familiarity" - we're not in a vacuum, folks would prefer to write / read
      code that interacts with these data structures in a "normal" kernel style

I will expand upon these, but FWIW the main point of this document is to explain
why new verifier functionality is necessary to make Graph datastructures work,
and what said new functionality does.

Explaining why map API is a bad fit is part of that, but I expect the reader to
have some experience writing BPF programs which interact with maps, so I
probably won't elaborate too much on the basics here. The sentence(s) added to
satisfy your "intended audience" suggestion will say as much.

>> +
>> +Luckily, some restrictions which necessitated the use of BPF map semantics are
>> +no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
>> +BPF allocator, it is now possible to implement BPF data structures whose API
>> +and semantics more closely match those exposed to the rest of the kernel.
> 
> Suggestion, I'd consider explicitly contrasting the map-type
> implementation here with the graph-type implementation. What do you
> think of something like this instead of the above paragraph:
> 
> BPF map-type data structures are defined as part of the UAPI in ``enum
> bpf_map_type``, and are accessed and manipulated using BPF
> :doc:`helpers`. The behaviors, backing memory, and implementations of
> these map-type data structures are entirely encapsulated from BPF
> programs, and mostly encapsulated from the verifier, by the helper
> functions. The logic in the verifier for ensuring that map-type data
> structures are correctly used therefore essentially amounts to
> statically verifying that the helper functions that manipulate and
> access the data structure are called correctly by the program, as
> defined in the helper prototypes. The verifier then relies on the helper
> to properly manipulate the backing data structure with its validated
> arguments.
>> BPF graph-type data structures, on the other hand, leverage more modern
> features such as :doc:`kfuncs`, kptrs, and the any-context BPF
> allocator. They allow BPF programs to manipulate the data structures
> directly using APIs and semantics which more closely match those exposed
> to code in the main kernel, with the verifier's job now being to ensure
> that the programs are properly manipulating the data structures, rather
> than relying on helper functions to properly manipulate the data
> structures in the main kernel.
> 

There's good info here, but I think it belongs in specific sections where
new approach is discussed, not in introduction. For "intended audience" reasons
touched on in my response above.

For "non-owning references section", I will add some paragraphs explaining why
there's no equivalent concept for Map API. For other things you touched on (UAPI
vs kptrs, prealloc vs any-context allocator, etc), I'll add other sections.

>> +
>> +Two such data structures - linked_list and rbtree - have many verification
>> +details in common. Because both have "root"s ("head" for linked_list) and
>> +"node"s, the verifier code and this document refer to common functionality
>> +as "graph_api", "graph_root", "graph_node", etc.
> 
> 
> 
>> +
>> +Unless otherwise stated, examples and semantics below apply to both graph data
>> +structures.
>> +
>> +Non-owning references
>> +---------------------
>> +
>> +**Motivation**
>> +
>> +Consider the following BPF code:
>> +
>> +.. code-block:: c
> 
> You need an extra newline here or the docs build will complain:
> 
> bpf-next/Documentation/bpf/graph_ds_impl.rst:46: ERROR: Error in "code-block" directive:
> maximum 1 argument(s) allowed, 9 supplied.
> 
> .. code-block:: c
>         struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
> 
>         bpf_spin_lock(&lock);
> 
>         bpf_rbtree_add(&tree, n); /* AFTER */
> 
>         bpf_spin_unlock(&lock);
> 

Ack

>> +        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
>> +
>> +        bpf_spin_lock(&lock);
>> +
>> +        bpf_rbtree_add(&tree, n); /* AFTER */
>> +
>> +        bpf_spin_unlock(&lock);
> 
> Also need a newline here or sphinx will get confused and think the
> vertical line is part of the code block.
> 

Ack, all sphinx build errors / warnings for this doc have been fixed.

>> +----
>> +
>> +From the verifier's perspective, after bpf_obj_new ``n`` has type
>> +``PTR_TO_BTF_ID | MEM_ALLOC`` with btf_id of ``struct node_data`` and a
>> +nonzero ``ref_obj_id``. Because it holds ``n``, the program has ownership
> 
> I had to read this first sentence a few times to parse it, maybe due to
> a missing comma between "after bpf_obj_new" and "``n`` has type...".
> What do you think about this wording?
> 
> From the verifier's perspective, the pointer ``n`` returned from
> ``bpf_obj_new`` has type ``PTR_TO_BTF_ID | MEM_ALLOC``, with a `btf_id`
> of ``struct node_data``, and a nonzero ``ref_obj_id``.
> 

Ack, your wording is better.

>> +of the pointee's lifetime (object pointed to by ``n``). The BPF program must
> 
> Should we move (object pointed to by ``n``) to be directly after
> "pointee's" / before "lifetime"? Otherwise it reads kind of odd given
> that "lifetime" is really the indirect object in the sentence.
> 

Ack.

>> +pass off ownership before exiting - either via ``bpf_obj_drop``, which free's
> 
> s/free's/frees
> 

I did ``free``'s and ``free``'d instead of these suggested changes. Want to make
it obvious that the action taken is equivalent to free() from malloc API.

>> +the object, or by adding it to ``tree`` with ``bpf_rbtree_add``.
>> +
>> +(``BEFORE`` and ``AFTER`` comments in the example denote beginning of "before
>> +ownership is passed" and "after ownership is passed")
> 
> Should we use something like ACQUIRED / PASSED / RELEASED instead of
> BEFORE / AFTER?
> 

Ack. None of the code samples need RELEASED comment yet, but this scheme is
easier to follow regardless.

>> +
>> +What should the verifier do with ``n`` after ownership is passed off? If the
>> +object was free'd with ``bpf_obj_drop`` the answer is obvious: the verifier
> 
> s/free'd/freed
> 
>> +should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as
>> +the object is no longer valid. The underlying memory may have been reused for
>> +some other allocation, unmapped, etc.
>> +
>> +When ownership is passed to ``tree`` via ``bpf_rbtree_add`` the answer is less
>> +obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
>> +but that would result in programs with useful, common coding patterns being
>> +rejected, e.g.:
>> +
>> +.. code-block:: c
> 
> Same here (newline)
> 
>> +        int x;
>> +        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
>> +
>> +        bpf_spin_lock(&lock);
>> +
>> +        bpf_rbtree_add(&tree, n); /* AFTER */
>> +        x = n->data;
>> +        n->data = 42;
>> +
>> +        bpf_spin_unlock(&lock);
> 
> Same here (newline)
> 
>> +----
>> +
>> +Both the read from and write to ``n->data`` would be rejected. The verifier
>> +can do better, though, by taking advantage of two details:
>> +
>> +  * Graph data structure APIs can only be used when the ``bpf_spin_lock``
>> +    associated with the graph root is held
> 
> I'd consider giving a bit more background information on this somewhere
> above. This is the first time we've mentioned anything about a lock, so
> it might be worth it to give some context on how these graph-type maps
> are defined and initialized.
> 
> I realize we could be approaching "useful even to people who aren't
> working on the verifier" territory if we go into too much detail, but I
> also think it's important to give backround context on this stuff
> regardless of the intended audience in order for the documentation to
> really be useful.
> 

Agreed, this document is missing important background information about
spin_locks + Graph Datastructures.

>> +  * Both graph data structures have pointer stability
> 
> You also need a newline between nested list entries or sphinx will get
> confused. My suggestion would be to just always have a newline between
> list entries (applies elsewhere in the file as well).
> 

Ack. Apparently I needed three spaces to trigger the next nesting level (had
two). After doing that, it was obvious why your "always have a newline"
suggestion is good.

>> +    * Because graph nodes are allocated with ``bpf_obj_new`` and
>> +      adding / removing from the root involves fiddling with the
>> +      ``bpf_{list,rb}_node`` field of the node struct, a graph node will
>> +      remain at the same address after either operation.
>> +
>> +Because the associated ``bpf_spin_lock`` must be held by any program adding
>> +or removing, if we're in the critical section bounded by that lock, we know
>> +that no other program can add or remove until the end of the critical section.
>> +This combined with pointer stability means that, until the critical section
>> +ends, we can safely access the graph node through ``n`` even after it was used
>> +to pass ownership.
>> +
>> +The verifier considers such a reference a *non-owning reference*. The ref
>> +returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
>> +Both terms currently only have meaning in the context of graph nodes and API.
>> +
>> +**Details**
>> +
>> +Let's enumerate the properties of both types of references.
>> +
>> +*owning reference*
>> +
>> +  * This reference controls the lifetime of the pointee
>> +  * Ownership of pointee must be 'released' by passing it to some graph API
>> +    kfunc, or via ``bpf_obj_drop``, which free's the pointee
> 
> s/free's/frees. "Frees" is a verb, "free's" is a possessive.
> 
>> +    * If not released before program ends, verifier considers program invalid
>> +  * Access to the pointee's memory will not page fault
>> +
>> +*non-owning reference*
>> +
>> +  * This reference does not own the pointee
>> +    * It cannot be used to add the graph node to a graph root, nor free via
>> +      ``bpf_obj_drop``
>> +  * No explicit control of lifetime, but can infer valid lifetime based on
>> +    non-owning ref existence (see explanation below)
>> +  * Access to the pointee's memory will not page fault
> 
> I'd consider defining references, or at least giving some high-level
> description of how they work, somewhere a bit earlier in the page. The
> "Non-owning references" section kind of just jumps right into examples
> of what the verifier allows without describing the concept at a higher
> level, so readers will have a difficult time applying what they're
> reading to the examples being provided.
> 
>> +
>> +From verifier's perspective non-owning references can only exist
>> +between spin_lock and spin_unlock. Why? After spin_unlock another program
>> +can do arbitrary operations on the data structure like removing and free-ing
> 
> s/free-ing/freeing
> 
>> +via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,
> 
> s/remove'd/removed

Similarly to ``free``'d, 'remove' here is referring to a specific function, so
did ``remove``'d instead.

> 
> I'll stop pointing these out for now, they apply throughout the page.
> 
>> +free'd, and reused via bpf_obj_new would point to an entirely different thing.
>> +Or the memory could go away.
>> +
>> +To prevent this logic violation all non-owning references are invalidated by
>> +verifier after critical section ends. This is necessary to ensure "will
> 
> - s/by verifier/by the verifier
> - s/after critical section/after a critical section
> - s/to ensure "will not"/to ensure a "will not"
> 
> 

Ack, except s/to ensure "will not"/to ensure the "will not"

>> +not page fault" property of non-owning reference. So if verifier hasn't
> 
> - s/of non-owning/of the non-owning
> - s/So if verifier/So if the verifier
> 

Ack, except s/of non-owning reference/of non-owning references

>> +invalidated a non-owning ref, accessing it will not page fault.
>> +
>> +Currently ``bpf_obj_drop`` is not allowed in the critical section, so
>> +if there's a valid non-owning ref, we must be in critical section, and can
> 
> s/in critical section/in a critical section
> 

Ack

>> +conclude that the ref's memory hasn't been dropped-and-free'd or dropped-
>> +and-reused.
> 
> If you split the line like this, it will render as "dropped-and- reused".
> 

Ack

>> +
>> +Any reference to a node that is in a rbtree _must_ be non-owning, since
> 
> s/a rbtree/an rbtree
> 

TIL, ack.

>> +the tree has control of pointee lifetime. Similarly, any ref to a node
> 
> s/of pointee lifetime/of the pointee's lifetime
> 

ack

>> +that isn't in rbtree _must_ be owning. This results in a nice property:
> 
> s/in rbtree/in an rbtree
> 

ack

>> +graph API add / remove implementations don't need to check if a node
>> +has already been added (or already removed), as the verifier type system
>> +prevents such a state from being valid.
> 
> I feel like "verifier type system" isn't quite accurate here, though I
> may be wrong. When I think of something like "verifier type system" I'm
> more envisioning how the verifier ensures that the correct BTF IDs are
> passed. In this case, it's really the BPF graph-object ownership model
> that's ensuring that the state is valid, right?
> 

I mean "type system" here in the PL / language runtime sense. Although the
verifier doesn't execute the code at runtime, at verification time it augments
the raw BPF bytecode with type information (BTF or type inferred from attach
context) and does some execution-like things with the program, including
complaining if some function expects type X but gets type Y as input.

In this case "owning reference" and "non-owning reference" are distinct types
(owning has nonzero ref_obj_id) and the verifier rejects wrong type for kfunc
input based on this info alone. "graph-object ownership model" is responsible
for changing refs of one type to another.

Regardless, your broader point stands - "verifier type system" isn't commonly
used to describe this behavior, so I should phrase this better.

>> +
>> +However, pointer aliasing poses an issue for the above "nice property".
>> +Consider the following example:
>> +
>> +.. code-block:: c
> 
> Same here (newline)
> 
>> +        struct node_data *n, *m, *o, *p;
>> +        n = bpf_obj_new(typeof(*n));     /* 1 */
>> +
>> +        bpf_spin_lock(&lock);
>> +
>> +        bpf_rbtree_add(&tree, n);        /* 2 */
>> +        m = bpf_rbtree_first(&tree);     /* 3 */
>> +
>> +        o = bpf_rbtree_remove(&tree, n); /* 4 */
>> +        p = bpf_rbtree_remove(&tree, m); /* 5 */
>> +
>> +        bpf_spin_unlock(&lock);
>> +
>> +        bpf_obj_drop(o);
>> +        bpf_obj_drop(p); /* 6 */
> 
> Same here (newline)
> 
>> +----
>> +
>> +Assume tree is empty before this program runs. If we track verifier state
> 
> s/Assume tree,/Assume the tree
> 

ack

>> +changes here using numbers in above comments:
>> +
>> +  1) n is an owning reference
>> +  2) n is a non-owning reference, it's been added to the tree
>> +  3) n and m are non-owning references, they both point to the same node
>> +  4) o is an owning reference, n and m non-owning, all point to same node
>> +  5) o and p are owning, n and m non-owning, all point to the same node
>> +  6) a double-free has occurred, since o and p point to same node and o was
>> +     free'd in previous statement
>> +
>> +States 4 and 5 violate our "nice property", as there are non-owning refs to
>> +a node which is not in a rbtree. Statement 5 will try to remove a node which
>> +has already been removed as a result of this violation. State 6 is a dangerous
>> +double-free.
>> +
>> +At a minimum we should prevent state 6 from being possible. If we can't also
>> +prevent state 5 then we must abandon our "nice property" and check whether a
>> +node has already been removed at runtime.
>> +
>> +We prevent both by generalizing the "invalidate non-owning references" behavior
>> +of ``bpf_spin_unlock`` and doing similar invalidation after
>> +``bpf_rbtree_remove``. The logic here being that any graph API kfunc which:
>> +
>> +  * takes an arbitrary node argument
>> +  * removes it from the datastructure
>> +  * returns an owning reference to the removed node
>> +
>> +May result in a state where some other non-owning reference points to the same
>> +node. So ``remove``-type kfuncs must be considered a non-owning reference
>> +invalidation point as well.
> 
> Could you please also add the new kfunc flags that signal this to
> Documentation/bpf/kfuncs.rst?
> 

ack

>> diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst
>> index 3d61963403b4..7e6b12018802 100644
>> --- a/Documentation/bpf/other.rst
>> +++ b/Documentation/bpf/other.rst
>> @@ -6,4 +6,5 @@ Other
>>     :maxdepth: 1
>>  
>>     ringbuf
>> -   llvm_reloc
>> \ No newline at end of file
>> +   llvm_reloc
>> +   graph_ds_impl
>> -- 
>> 2.30.2
>>

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs
  2023-01-18  2:16     ` Dave Marchevsky
@ 2023-01-20  4:45       ` David Vernet
  0 siblings, 0 replies; 37+ messages in thread
From: David Vernet @ 2023-01-20  4:45 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: Dave Marchevsky, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Kernel Team, Kumar Kartikeya Dwivedi, Tejun Heo

On Tue, Jan 17, 2023 at 09:16:00PM -0500, Dave Marchevsky wrote:
> On 12/28/22 4:26 PM, David Vernet wrote:
> > On Sat, Dec 17, 2022 at 12:25:06AM -0800, Dave Marchevsky wrote:
> >> It is difficult to intuit the semantics of owning and non-owning
> >> references from verifier code. In order to keep the high-level details
> >> from being lost in the mailing list, this patch adds documentation
> >> explaining semantics and details.
> >>
> >> The target audience of doc added in this patch is folks working on BPF
> >> internals, as there's focus on "what should the verifier do here". Via
> >> reorganization or copy-and-paste, much of the content can probably be
> >> repurposed for BPF program writer audience as well.
> >>
> >> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> > 
> > Hey Dave,
> > 
> > Thanks for writing this up. I left a few comments and suggestions as a
> > first pass. Feel free to push back on any of them.
> > 
> >> ---
> >>  Documentation/bpf/graph_ds_impl.rst | 208 ++++++++++++++++++++++++++++
> >>  Documentation/bpf/other.rst         |   3 +-
> >>  2 files changed, 210 insertions(+), 1 deletion(-)
> >>  create mode 100644 Documentation/bpf/graph_ds_impl.rst
> >>
> >> diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
> >> new file mode 100644
> >> index 000000000000..f92cbd223dc3
> >> --- /dev/null
> >> +++ b/Documentation/bpf/graph_ds_impl.rst
> >> @@ -0,0 +1,208 @@
> >> +=========================
> >> +BPF Graph Data Structures
> >> +=========================
> >> +
> >> +This document describes implementation details of new-style "graph" data
> >> +structures (linked_list, rbtree), with particular focus on verifier
> > 
> > s/with particular/with a particular
> > 
> 
> I'm no grammar expert, but based on my googling
> "with particular focus" is widely used in newspapers and other places
> where grammarians lurk.

I have no doubt whatsoever that people who write professionally know
better than I do, so yeah, I'm probably wrong and it's fine to leave it
as is.

> 
> >> +implementation of semantics particular to those data structures.
> > 
> > s/particular/specific
> > 
> > Just because we already use the word "particular" in the sentence?
> > 
> 
> Ack
> 
> > In general this sentence feels a bit difficult to parse. Wdyt about
> > this?
> > 
> > ...with a particular focus on how the verifier ensures that they are
> > properly and safely used by BPF programs.
> > 
> 
> Agreed in general, but re: your specific suggestion: "the verifier's
> implementation of semantics specific to those data structures" communicates
> that there are semantics specific to those data structures which required
> verifier changes. 
> 
> "ensures that they are properly and safely used by BPF programs" is more
> vague, but definitely easier to parse.
> 
> Will rewrite in some other way which is hopefully best of both worlds.

Yeah that's fair, feel free to keep the way you had it before if you
prefer that. Or reword it, up to you.

> 
> >> +
> >> +Note that the intent of this document is to describe the current state of
> >> +these graph data structures, **no guarantees** of stability for either
> > 
> > I think we can end the sentence in the middle here.
> > 
> > ...these graph data structures. **No guarantees**...
> 
> Ack
> 
> > 
> > Should we also add a sentence or two here about the intended audience
> > (people working on the verifier or readers who are interested in
> > learning more about BPF internals)?
> > 
> 
> Ack
> 
> >> +semantics or APIs are made or implied here.
> >> +
> >> +.. contents::
> >> +    :local:
> >> +    :depth: 2
> >> +
> >> +Introduction
> >> +------------
> >> +
> >> +The BPF map API has historically been the main way to expose data structures
> >> +of various types for use within BPF programs. Some data structures fit naturally
> >> +with the map API (HASH, ARRAY), others less so. Consequentially, programs
> > 
> > Would you mind please adding some details on why some data structures
> > don't fit naturally into the existing map APIs? I feel like that's kind
> > of the main focus of the article, so it would probably help to give some
> > high-level context up front.
> > 
> >> +interacting with the latter group of data structures can be hard to parse
> >> +for kernel programmers without previous BPF experience.
> > 
> > I'm not sure I quite follow how this latter point about data structures
> > being hard to parse is derived from the point about how some data
> > structures don't fit naturally with the map APIs. Maybe we should say
> > something like:
> > 
> > ..., others less so. Given that the API surface and behavioral semantics
> > are fundmentally different between these two classes of BPF data
> > structures, kernel programmers who are used to interacting with map-type
> > data structures may find these graph-type data structures to be
> > confusing or unfamiliar.
> > 
> > Wdyt?
> > 
> 
> The "Introduction" section is trying to make these points:
> 
>   * Data structures have historically been forced to adhere to the Map API
>   * Some data structures (linked list, rbtree) don't fit the Map API well
>   * For data stuctures that don't fit the Map API well, two problems would
>     arise if they were exposed as maps:
>     * "square peg / round hole" - in a vacuum, it'd be hard to make sense
>       of how Map API manipulates those data structures
>     * "Familiarity" - we're not in a vacuum, folks would prefer to write / read
>       code that interacts with these data structures in a "normal" kernel style
> 
> I will expand upon these, but FWIW the main point of this document is to explain
> why new verifier functionality is necessary to make Graph datastructures work,
> and what said new functionality does.
> 
> Explaining why map API is a bad fit is part of that, but I expect the reader to
> have some experience writing BPF programs which interact with maps, so I
> probably won't elaborate too much on the basics here. The sentence(s) added to
> satisfy your "intended audience" suggestion will say as much.
> 
> >> +
> >> +Luckily, some restrictions which necessitated the use of BPF map semantics are
> >> +no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
> >> +BPF allocator, it is now possible to implement BPF data structures whose API
> >> +and semantics more closely match those exposed to the rest of the kernel.
> > 
> > Suggestion, I'd consider explicitly contrasting the map-type
> > implementation here with the graph-type implementation. What do you
> > think of something like this instead of the above paragraph:
> > 
> > BPF map-type data structures are defined as part of the UAPI in ``enum
> > bpf_map_type``, and are accessed and manipulated using BPF
> > :doc:`helpers`. The behaviors, backing memory, and implementations of
> > these map-type data structures are entirely encapsulated from BPF
> > programs, and mostly encapsulated from the verifier, by the helper
> > functions. The logic in the verifier for ensuring that map-type data
> > structures are correctly used therefore essentially amounts to
> > statically verifying that the helper functions that manipulate and
> > access the data structure are called correctly by the program, as
> > defined in the helper prototypes. The verifier then relies on the helper
> > to properly manipulate the backing data structure with its validated
> > arguments.
> >> BPF graph-type data structures, on the other hand, leverage more modern
> > features such as :doc:`kfuncs`, kptrs, and the any-context BPF
> > allocator. They allow BPF programs to manipulate the data structures
> > directly using APIs and semantics which more closely match those exposed
> > to code in the main kernel, with the verifier's job now being to ensure
> > that the programs are properly manipulating the data structures, rather
> > than relying on helper functions to properly manipulate the data
> > structures in the main kernel.
> > 
> 
> There's good info here, but I think it belongs in specific sections where
> new approach is discussed, not in introduction. For "intended audience" reasons
> touched on in my response above.

Sounds good.

> For "non-owning references section", I will add some paragraphs explaining why
> there's no equivalent concept for Map API. For other things you touched on (UAPI
> vs kptrs, prealloc vs any-context allocator, etc), I'll add other sections.

Thanks!

> 
> >> +
> >> +Two such data structures - linked_list and rbtree - have many verification
> >> +details in common. Because both have "root"s ("head" for linked_list) and
> >> +"node"s, the verifier code and this document refer to common functionality
> >> +as "graph_api", "graph_root", "graph_node", etc.
> > 
> > 
> > 
> >> +
> >> +Unless otherwise stated, examples and semantics below apply to both graph data
> >> +structures.
> >> +
> >> +Non-owning references
> >> +---------------------
> >> +
> >> +**Motivation**
> >> +
> >> +Consider the following BPF code:
> >> +
> >> +.. code-block:: c
> > 
> > You need an extra newline here or the docs build will complain:
> > 
> > bpf-next/Documentation/bpf/graph_ds_impl.rst:46: ERROR: Error in "code-block" directive:
> > maximum 1 argument(s) allowed, 9 supplied.
> > 
> > .. code-block:: c
> >         struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
> > 
> >         bpf_spin_lock(&lock);
> > 
> >         bpf_rbtree_add(&tree, n); /* AFTER */
> > 
> >         bpf_spin_unlock(&lock);
> > 
> 
> Ack
> 
> >> +        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
> >> +
> >> +        bpf_spin_lock(&lock);
> >> +
> >> +        bpf_rbtree_add(&tree, n); /* AFTER */
> >> +
> >> +        bpf_spin_unlock(&lock);
> > 
> > Also need a newline here or sphinx will get confused and think the
> > vertical line is part of the code block.
> > 
> 
> Ack, all sphinx build errors / warnings for this doc have been fixed.
> 
> >> +----
> >> +
> >> +From the verifier's perspective, after bpf_obj_new ``n`` has type
> >> +``PTR_TO_BTF_ID | MEM_ALLOC`` with btf_id of ``struct node_data`` and a
> >> +nonzero ``ref_obj_id``. Because it holds ``n``, the program has ownership
> > 
> > I had to read this first sentence a few times to parse it, maybe due to
> > a missing comma between "after bpf_obj_new" and "``n`` has type...".
> > What do you think about this wording?
> > 
> > From the verifier's perspective, the pointer ``n`` returned from
> > ``bpf_obj_new`` has type ``PTR_TO_BTF_ID | MEM_ALLOC``, with a `btf_id`
> > of ``struct node_data``, and a nonzero ``ref_obj_id``.
> > 
> 
> Ack, your wording is better.
> 
> >> +of the pointee's lifetime (object pointed to by ``n``). The BPF program must
> > 
> > Should we move (object pointed to by ``n``) to be directly after
> > "pointee's" / before "lifetime"? Otherwise it reads kind of odd given
> > that "lifetime" is really the indirect object in the sentence.
> > 
> 
> Ack.
> 
> >> +pass off ownership before exiting - either via ``bpf_obj_drop``, which free's
> > 
> > s/free's/frees
> > 
> 
> I did ``free``'s and ``free``'d instead of these suggested changes. Want to make
> it obvious that the action taken is equivalent to free() from malloc API.
> 
> >> +the object, or by adding it to ``tree`` with ``bpf_rbtree_add``.
> >> +
> >> +(``BEFORE`` and ``AFTER`` comments in the example denote beginning of "before
> >> +ownership is passed" and "after ownership is passed")
> > 
> > Should we use something like ACQUIRED / PASSED / RELEASED instead of
> > BEFORE / AFTER?
> > 
> 
> Ack. None of the code samples need RELEASED comment yet, but this scheme is
> easier to follow regardless.
> 
> >> +
> >> +What should the verifier do with ``n`` after ownership is passed off? If the
> >> +object was free'd with ``bpf_obj_drop`` the answer is obvious: the verifier
> > 
> > s/free'd/freed
> > 
> >> +should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as
> >> +the object is no longer valid. The underlying memory may have been reused for
> >> +some other allocation, unmapped, etc.
> >> +
> >> +When ownership is passed to ``tree`` via ``bpf_rbtree_add`` the answer is less
> >> +obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
> >> +but that would result in programs with useful, common coding patterns being
> >> +rejected, e.g.:
> >> +
> >> +.. code-block:: c
> > 
> > Same here (newline)
> > 
> >> +        int x;
> >> +        struct node_data *n = bpf_obj_new(typeof(*n)); /* BEFORE */
> >> +
> >> +        bpf_spin_lock(&lock);
> >> +
> >> +        bpf_rbtree_add(&tree, n); /* AFTER */
> >> +        x = n->data;
> >> +        n->data = 42;
> >> +
> >> +        bpf_spin_unlock(&lock);
> > 
> > Same here (newline)
> > 
> >> +----
> >> +
> >> +Both the read from and write to ``n->data`` would be rejected. The verifier
> >> +can do better, though, by taking advantage of two details:
> >> +
> >> +  * Graph data structure APIs can only be used when the ``bpf_spin_lock``
> >> +    associated with the graph root is held
> > 
> > I'd consider giving a bit more background information on this somewhere
> > above. This is the first time we've mentioned anything about a lock, so
> > it might be worth it to give some context on how these graph-type maps
> > are defined and initialized.
> > 
> > I realize we could be approaching "useful even to people who aren't
> > working on the verifier" territory if we go into too much detail, but I
> > also think it's important to give backround context on this stuff
> > regardless of the intended audience in order for the documentation to
> > really be useful.
> > 
> 
> Agreed, this document is missing important background information about
> spin_locks + Graph Datastructures.
> 
> >> +  * Both graph data structures have pointer stability
> > 
> > You also need a newline between nested list entries or sphinx will get
> > confused. My suggestion would be to just always have a newline between
> > list entries (applies elsewhere in the file as well).
> > 
> 
> Ack. Apparently I needed three spaces to trigger the next nesting level (had
> two). After doing that, it was obvious why your "always have a newline"
> suggestion is good.
> 
> >> +    * Because graph nodes are allocated with ``bpf_obj_new`` and
> >> +      adding / removing from the root involves fiddling with the
> >> +      ``bpf_{list,rb}_node`` field of the node struct, a graph node will
> >> +      remain at the same address after either operation.
> >> +
> >> +Because the associated ``bpf_spin_lock`` must be held by any program adding
> >> +or removing, if we're in the critical section bounded by that lock, we know
> >> +that no other program can add or remove until the end of the critical section.
> >> +This combined with pointer stability means that, until the critical section
> >> +ends, we can safely access the graph node through ``n`` even after it was used
> >> +to pass ownership.
> >> +
> >> +The verifier considers such a reference a *non-owning reference*. The ref
> >> +returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
> >> +Both terms currently only have meaning in the context of graph nodes and API.
> >> +
> >> +**Details**
> >> +
> >> +Let's enumerate the properties of both types of references.
> >> +
> >> +*owning reference*
> >> +
> >> +  * This reference controls the lifetime of the pointee
> >> +  * Ownership of pointee must be 'released' by passing it to some graph API
> >> +    kfunc, or via ``bpf_obj_drop``, which free's the pointee
> > 
> > s/free's/frees. "Frees" is a verb, "free's" is a possessive.
> > 
> >> +    * If not released before program ends, verifier considers program invalid
> >> +  * Access to the pointee's memory will not page fault
> >> +
> >> +*non-owning reference*
> >> +
> >> +  * This reference does not own the pointee
> >> +    * It cannot be used to add the graph node to a graph root, nor free via
> >> +      ``bpf_obj_drop``
> >> +  * No explicit control of lifetime, but can infer valid lifetime based on
> >> +    non-owning ref existence (see explanation below)
> >> +  * Access to the pointee's memory will not page fault
> > 
> > I'd consider defining references, or at least giving some high-level
> > description of how they work, somewhere a bit earlier in the page. The
> > "Non-owning references" section kind of just jumps right into examples
> > of what the verifier allows without describing the concept at a higher
> > level, so readers will have a difficult time applying what they're
> > reading to the examples being provided.
> > 
> >> +
> >> +From verifier's perspective non-owning references can only exist
> >> +between spin_lock and spin_unlock. Why? After spin_unlock another program
> >> +can do arbitrary operations on the data structure like removing and free-ing
> > 
> > s/free-ing/freeing
> > 
> >> +via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,
> > 
> > s/remove'd/removed
> 
> Similarly to ``free``'d, 'remove' here is referring to a specific function, so
> did ``remove``'d instead.
> 
> > 
> > I'll stop pointing these out for now, they apply throughout the page.
> > 
> >> +free'd, and reused via bpf_obj_new would point to an entirely different thing.
> >> +Or the memory could go away.
> >> +
> >> +To prevent this logic violation all non-owning references are invalidated by
> >> +verifier after critical section ends. This is necessary to ensure "will
> > 
> > - s/by verifier/by the verifier
> > - s/after critical section/after a critical section
> > - s/to ensure "will not"/to ensure a "will not"
> > 
> > 
> 
> Ack, except s/to ensure "will not"/to ensure the "will not"
> 
> >> +not page fault" property of non-owning reference. So if verifier hasn't
> > 
> > - s/of non-owning/of the non-owning
> > - s/So if verifier/So if the verifier
> > 
> 
> Ack, except s/of non-owning reference/of non-owning references
> 
> >> +invalidated a non-owning ref, accessing it will not page fault.
> >> +
> >> +Currently ``bpf_obj_drop`` is not allowed in the critical section, so
> >> +if there's a valid non-owning ref, we must be in critical section, and can
> > 
> > s/in critical section/in a critical section
> > 
> 
> Ack
> 
> >> +conclude that the ref's memory hasn't been dropped-and-free'd or dropped-
> >> +and-reused.
> > 
> > If you split the line like this, it will render as "dropped-and- reused".
> > 
> 
> Ack
> 
> >> +
> >> +Any reference to a node that is in a rbtree _must_ be non-owning, since
> > 
> > s/a rbtree/an rbtree
> > 
> 
> TIL, ack.
> 
> >> +the tree has control of pointee lifetime. Similarly, any ref to a node
> > 
> > s/of pointee lifetime/of the pointee's lifetime
> > 
> 
> ack
> 
> >> +that isn't in rbtree _must_ be owning. This results in a nice property:
> > 
> > s/in rbtree/in an rbtree
> > 
> 
> ack
> 
> >> +graph API add / remove implementations don't need to check if a node
> >> +has already been added (or already removed), as the verifier type system
> >> +prevents such a state from being valid.
> > 
> > I feel like "verifier type system" isn't quite accurate here, though I
> > may be wrong. When I think of something like "verifier type system" I'm
> > more envisioning how the verifier ensures that the correct BTF IDs are
> > passed. In this case, it's really the BPF graph-object ownership model
> > that's ensuring that the state is valid, right?
> > 
> 
> I mean "type system" here in the PL / language runtime sense. Although the
> verifier doesn't execute the code at runtime, at verification time it augments
> the raw BPF bytecode with type information (BTF or type inferred from attach
> context) and does some execution-like things with the program, including
> complaining if some function expects type X but gets type Y as input.
> 
> In this case "owning reference" and "non-owning reference" are distinct types
> (owning has nonzero ref_obj_id) and the verifier rejects wrong type for kfunc
> input based on this info alone. "graph-object ownership model" is responsible
> for changing refs of one type to another.
> 
> Regardless, your broader point stands - "verifier type system" isn't commonly
> used to describe this behavior, so I should phrase this better.

Thanks for explaining. That all makes sense, but yeah, might be worth
tinkering with the wording a bit just to avoid future confusion for
others.

> 
> >> +
> >> +However, pointer aliasing poses an issue for the above "nice property".
> >> +Consider the following example:
> >> +
> >> +.. code-block:: c
> > 
> > Same here (newline)
> > 
> >> +        struct node_data *n, *m, *o, *p;
> >> +        n = bpf_obj_new(typeof(*n));     /* 1 */
> >> +
> >> +        bpf_spin_lock(&lock);
> >> +
> >> +        bpf_rbtree_add(&tree, n);        /* 2 */
> >> +        m = bpf_rbtree_first(&tree);     /* 3 */
> >> +
> >> +        o = bpf_rbtree_remove(&tree, n); /* 4 */
> >> +        p = bpf_rbtree_remove(&tree, m); /* 5 */
> >> +
> >> +        bpf_spin_unlock(&lock);
> >> +
> >> +        bpf_obj_drop(o);
> >> +        bpf_obj_drop(p); /* 6 */
> > 
> > Same here (newline)
> > 
> >> +----
> >> +
> >> +Assume tree is empty before this program runs. If we track verifier state
> > 
> > s/Assume tree,/Assume the tree
> > 
> 
> ack
> 
> >> +changes here using numbers in above comments:
> >> +
> >> +  1) n is an owning reference
> >> +  2) n is a non-owning reference, it's been added to the tree
> >> +  3) n and m are non-owning references, they both point to the same node
> >> +  4) o is an owning reference, n and m non-owning, all point to same node
> >> +  5) o and p are owning, n and m non-owning, all point to the same node
> >> +  6) a double-free has occurred, since o and p point to same node and o was
> >> +     free'd in previous statement
> >> +
> >> +States 4 and 5 violate our "nice property", as there are non-owning refs to
> >> +a node which is not in a rbtree. Statement 5 will try to remove a node which
> >> +has already been removed as a result of this violation. State 6 is a dangerous
> >> +double-free.
> >> +
> >> +At a minimum we should prevent state 6 from being possible. If we can't also
> >> +prevent state 5 then we must abandon our "nice property" and check whether a
> >> +node has already been removed at runtime.
> >> +
> >> +We prevent both by generalizing the "invalidate non-owning references" behavior
> >> +of ``bpf_spin_unlock`` and doing similar invalidation after
> >> +``bpf_rbtree_remove``. The logic here being that any graph API kfunc which:
> >> +
> >> +  * takes an arbitrary node argument
> >> +  * removes it from the datastructure
> >> +  * returns an owning reference to the removed node
> >> +
> >> +May result in a state where some other non-owning reference points to the same
> >> +node. So ``remove``-type kfuncs must be considered a non-owning reference
> >> +invalidation point as well.
> > 
> > Could you please also add the new kfunc flags that signal this to
> > Documentation/bpf/kfuncs.rst?
> > 
> 
> ack
> 
> >> diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst
> >> index 3d61963403b4..7e6b12018802 100644
> >> --- a/Documentation/bpf/other.rst
> >> +++ b/Documentation/bpf/other.rst
> >> @@ -6,4 +6,5 @@ Other
> >>     :maxdepth: 1
> >>  
> >>     ringbuf
> >> -   llvm_reloc
> >> \ No newline at end of file
> >> +   llvm_reloc
> >> +   graph_ds_impl
> >> -- 
> >> 2.30.2
> >>

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs
  2023-01-17 17:26         ` Dave Marchevsky
  2023-01-17 17:36           ` Alexei Starovoitov
@ 2023-01-20  5:13           ` David Vernet
  1 sibling, 0 replies; 37+ messages in thread
From: David Vernet @ 2023-01-20  5:13 UTC (permalink / raw)
  To: Dave Marchevsky
  Cc: Alexei Starovoitov, Dave Marchevsky, bpf, Alexei Starovoitov,
	Daniel Borkmann, Andrii Nakryiko, Kernel Team,
	Kumar Kartikeya Dwivedi, Tejun Heo

On Tue, Jan 17, 2023 at 12:26:32PM -0500, Dave Marchevsky wrote:
> On 12/29/22 12:00 PM, David Vernet wrote:
> > On Thu, Dec 29, 2022 at 08:50:19AM -0800, Alexei Starovoitov wrote:
> >> On Wed, Dec 28, 2022 at 10:40 PM David Vernet <void@manifault.com> wrote:
> >>>
> >>> On Sat, Dec 17, 2022 at 12:24:54AM -0800, Dave Marchevsky wrote:
> >>>> Currently, kfuncs marked KF_RELEASE indicate that they release some
> >>>> previously-acquired arg. The verifier assumes that such a function will
> >>>> only have one arg reg w/ ref_obj_id set, and that that arg is the one to
> >>>> be released. Multiple kfunc arg regs have ref_obj_id set is considered
> >>>> an invalid state.
> >>>>
> >>>> For helpers, RELEASE is used to tag a particular arg in the function
> >>>> proto, not the function itself. The arg with OBJ_RELEASE type tag is the
> >>>> arg that the helper will release. There can only be one such tagged arg.
> >>>> When verifying arg regs, multiple helper arg regs w/ ref_obj_id set is
> >>>> also considered an invalid state.
> >>>>
> >>>> Later patches in this series will result in some linked_list helpers
> >>>> marked KF_RELEASE having a valid reason to take two ref_obj_id args.
> >>>> Specifically, bpf_list_push_{front,back} can push a node to a list head
> >>>> which is itself part of a list node. In such a scenario both arguments
> >>>> to these functions would have ref_obj_id > 0, thus would fail
> >>>> verification under current logic.
> >>>>
> >>>> This patch changes kfunc ref_obj_id searching logic to find the last arg
> >>>> reg w/ ref_obj_id and consider that the reg-to-release. This should be
> >>>> backwards-compatible with all current kfuncs as they only expect one
> >>>> such arg reg.
> >>>
> >>> Can't say I'm a huge fan of this proposal :-( While I think it's really
> >>> unfortunate that kfunc flags are not defined per-arg for this exact type
> >>> of reason, adding more flag-specific semantics like this is IMO a step
> >>> in the wrong direction.  It's similar to the existing __sz and __k
> >>> argument-naming semantics that inform the verifier that the arguments
> >>> have special meaning. All of these little additions of special-case
> >>> handling for kfunc flags end up requiring people writing kfuncs (and
> >>> sometimes calling them) to read through the verifier to understand
> >>> what's going on (though I will say that it's nice that __sz and __k are
> >>> properly documented in [0]).
> >>
> >> Before getting to pros/cons of KF_* vs name suffix vs helper style
> >> per-arg description...
> >> It's important to highlight that here we're talking about
> >> link list and rb tree kfuncs that are not like other kfuncs.
> >> Majority of kfuncs can be added by subsystems like hid-bpf
> >> without touching the verifier.
> > 
> > I hear you and I agree. It wasn't my intention to drag us into a larger
> > discussion about kfuncs vs. helpers, but rather just to point out that I
> > think we have to try hard to avoid adding special-case logic that
> > requires looking into the verifier to understand the semantics. I think
> > we're on the same page about this, based on this and your other
> > response.
> > 
> 
> In another thread you also mentioned that hypothetical "kfunc writer" persona
> shouldn't have to understand kfunc flags in order to add their simple kfunc, and
> I think your comments here are also presupposing a "kfunc writer" persona that
> doesn't look at the verifier. Having such a person able to add kfuncs without
> understanding the verifier is a good goal, but doesn't reflect current
> reality when the kfunc needs to have any special semantics.

Agreed that it's the current reality that you need to read the verifier
to add kfuncs, but I disagree with the sentiment that it's therefore
acceptable to add what are arguably somewhat odd semantics in the
interim that move us in the opposite direction of getting there.

> Regardless, I'd expect that anyone adding further new-style Graph
> datastructures, old-style maps, or new datastructures unrelated to either,
> will be closer to "verifier expert" than "random person adding a few kfuncs".

This doesn't affect just graph datastructure kfunc authors though, it
affects anyone adding a kfunc. It just happens to be needed specifically
for graph data structures. If we really end up needing this, IMO it
would be better to get rid of KF_ACQUIRE and KF_RELEASE flags and just
use __acq / __rel suffixes to match __k and __sz.

> 
> >> Here we're paving the way for graph (aka new gen data structs)
> >> and so far not only kfuncs, but their arg types have to have
> >> special handling inside the verifier.
> >> There is not much yet to generalize and expose as generic KF_
> >> flag or as a name suffix.
> >> Therefore I think it's more appropriate to implement them
> >> with minimal verifier changes and minimal complexity.
> > 
> > Agreed
> > 
> 
> 'Generalize' was addressed in Patch 2's thread.
> 
> >> There is no 3rd graph algorithm on the horizon after link list
> >> and rbtree. Instead there is a big todo list for
> >> 'multi owner graph node' and 'bpf_refcount_t'.
> > 
> > In this case my point in [0] of the only option for generalizing being
> > to have something like KF_GRAPH_INSERT / KF_GRAPH_REMOVE is just not the
> > way forward (which I also said was my opinion when I pointed it out as
> > an option). Let's just special-case these kfuncs. There's already a
> > precedence for doing that in the verifier anyways. Minimal complexity,
> > minimal API changes. It's a win-win.
> > 
> > [0]: https://lore.kernel.org/all/Y63GLqZil9l1NzY4@maniforge.lan/
> > 
> 
> There's certainly precedent for adding special-case "kfunc_id == KFUNC_whatever"
> all over the verifier. It's a bad precedent, though, for reasons discussed in
> [0].
> 
> To specifically address your points here, I don't buy the argument that
> special-casing based on func id is "minimal complexity, minimal API changes".
> Re: 'complexity': the logic implementing the complicated semantic will be
> added regardless, it just won't have a name that's easily referenced in docs
> and mailing list discussions.
> 
> Similarly, re: 'API changes': if by 'API' here you mean "API that's exposed
> to folks adding kfuncs" - see my comments about "kfunc writer" persona above.
> We can think of the verifier itself as an API too - with a single bpf_check
> function. That API's behavior is indeed changed here, regardless of whether
> the added semantics are gated by a kfunc flag or special-case checks. I don't
> think that hiding complexity behind special-case checks when there could be
> a named flag simplifies anything. The complexity is added regardless, question
> is how many breadcrumbs and pointers we want to leave for folks trying to make
> sense of it in the future.
> 
>   [0]: https://lore.kernel.org/bpf/9763aed7-0284-e400-b4dc-ed01718d8e1e@meta.com/

Will reply on that thread.

> 
> >> Those will require bigger changes in the verifier,
> >> so I'd like to avoid premature generalization :) as analogous
> >> to premature optimization :)
> > 
> > And of course given my points above and in other threads: agreed. I
> > think we have an ideal middle-ground for minimizing complexity in the
> > short term, and some nice follow-on todo-list items to work on in the
> > medium-long term which will continue to improve things without
> > (negatively) affecting users in any way. All SGTM

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2023-01-20  5:23 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-17  8:24 [PATCH v2 bpf-next 00/13] BPF rbtree next-gen datastructure Dave Marchevsky
2022-12-17  8:24 ` [PATCH v2 bpf-next 01/13] bpf: Support multiple arg regs w/ ref_obj_id for kfuncs Dave Marchevsky
2022-12-29  3:24   ` Alexei Starovoitov
2022-12-29  6:40   ` David Vernet
2022-12-29 16:50     ` Alexei Starovoitov
2022-12-29 17:00       ` David Vernet
2023-01-17 17:26         ` Dave Marchevsky
2023-01-17 17:36           ` Alexei Starovoitov
2023-01-17 23:12             ` Dave Marchevsky
2023-01-20  5:13           ` David Vernet
2022-12-17  8:24 ` [PATCH v2 bpf-next 02/13] bpf: Migrate release_on_unlock logic to non-owning ref semantics Dave Marchevsky
2022-12-17  9:21   ` Dave Marchevsky
2022-12-23 10:51   ` Dan Carpenter
2022-12-28 23:46   ` David Vernet
2022-12-29 15:39     ` David Vernet
2022-12-29  3:56   ` Alexei Starovoitov
2022-12-29 16:54     ` David Vernet
2023-01-17 16:54       ` Dave Marchevsky
2023-01-17 16:07     ` Dave Marchevsky
2023-01-17 16:56       ` Alexei Starovoitov
2022-12-17  8:24 ` [PATCH v2 bpf-next 03/13] selftests/bpf: Update linked_list tests for " Dave Marchevsky
2022-12-17  8:24 ` [PATCH v2 bpf-next 04/13] bpf: rename list_head -> graph_root in field info types Dave Marchevsky
2022-12-17  8:24 ` [PATCH v2 bpf-next 05/13] bpf: Add basic bpf_rb_{root,node} support Dave Marchevsky
2022-12-17  8:24 ` [PATCH v2 bpf-next 06/13] bpf: Add bpf_rbtree_{add,remove,first} kfuncs Dave Marchevsky
2022-12-17  8:25 ` [PATCH v2 bpf-next 07/13] bpf: Add support for bpf_rb_root and bpf_rb_node in kfunc args Dave Marchevsky
2022-12-29  4:00   ` Alexei Starovoitov
2022-12-17  8:25 ` [PATCH v2 bpf-next 08/13] bpf: Add callback validation to kfunc verifier logic Dave Marchevsky
2022-12-17  8:25 ` [PATCH v2 bpf-next 09/13] bpf: Special verifier handling for bpf_rbtree_{remove, first} Dave Marchevsky
2022-12-29  4:02   ` Alexei Starovoitov
2022-12-17  8:25 ` [PATCH v2 bpf-next 10/13] bpf: Add bpf_rbtree_{add,remove,first} decls to bpf_experimental.h Dave Marchevsky
2022-12-17  8:25 ` [PATCH v2 bpf-next 11/13] libbpf: Make BTF mandatory if program BTF has spin_lock or alloc_obj type Dave Marchevsky
2022-12-22 18:50   ` Andrii Nakryiko
2022-12-17  8:25 ` [PATCH v2 bpf-next 12/13] selftests/bpf: Add rbtree selftests Dave Marchevsky
2022-12-17  8:25 ` [PATCH v2 bpf-next 13/13] bpf, documentation: Add graph documentation for non-owning refs Dave Marchevsky
2022-12-28 21:26   ` David Vernet
2023-01-18  2:16     ` Dave Marchevsky
2023-01-20  4:45       ` David Vernet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).