Re: [PATCH bpf-next v2 01/13] bpf: move linked-scalar flags out of bpf_reg_state->id [NFC]

[bot+bpf-ci]

> diff --git a/kernel/bpf/states.c b/kernel/bpf/states.c
> index 66fb11b6c6a7..d974baad37ee 100644
> --- a/kernel/bpf/states.c
> +++ b/kernel/bpf/states.c

[ ... ]

> @@ -369,13 +369,6 @@ static bool check_ids(u32 old_id, u32 cur_id, struct bpf_idmap *idmap)
>   * and r7.id=0 (both independent), without temp IDs both would map old_id=X
>   * to cur_id=0 and pass. With temp IDs: r6 maps X->temp1, r7 tries to map
>   * X->temp2, but X is already mapped to temp1, so the check fails correctly.
> - *
> - * When old_id has BPF_ADD_CONST set, the compound id (base | flag) and the
> - * base id (flag stripped) must both map consistently. Example: old has
> - * r2.id=A, r3.id=A|flag (r3 = r2 + delta), cur has r2.id=B, r3.id=C|flag
> - * (r3 derived from unrelated r4). Without the base check, idmap gets two
> - * independent entries A->B and A|flag->C|flag, missing that A->C conflicts
> - * with A->B. The base ID cross-check catches this.
>   */
>  static bool check_scalar_ids(u32 old_id, u32 cur_id, struct bpf_idmap *idmap)
>  {
> @@ -384,15 +377,7 @@ static bool check_scalar_ids(u32 old_id, u32 cur_id, struct bpf_idmap *idmap)
>
>  	cur_id = cur_id ? cur_id : ++idmap->tmp_id_gen;
>
> -	if (!check_ids(old_id, cur_id, idmap))
> -		return false;
> -	if (old_id & BPF_ADD_CONST) {
> -		old_id &= ~BPF_ADD_CONST;
> -		cur_id &= ~BPF_ADD_CONST;
> -		if (!check_ids(old_id, cur_id, idmap))
> -			return false;
> -	}
> -	return true;
> +	return check_ids(old_id, cur_id, idmap);
>  }

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
> index d571fbfc86a3..da6cb961a520 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_linked_scalars.c

[ ... ]

> @@ -648,10 +648,10 @@ l_exit_%=:							\
>  }
>
>  /*
> - * Test that regsafe() verifies base_id consistency for BPF_ADD_CONST
> + * Test that regsafe() verifies base_id consistency for ADD_CONST_*
>   * linked scalars during state pruning.
>   *
> - * The false branch (explored first) links R3 to R2 via ADD_CONST.
> + * The false branch (explored first) links R3 to R2 via ADD_CONST_64.
>   * The true branch (runtime path) links R3 to R4 (unrelated base_id).
>   * At the merge point, pruning must fail because the linkage topology
>   * differs.

Does this comment still match what the code does? The patch removes the
"base_id" concept from kernel/bpf/states.c (deleted the paragraph that
defined it, removed the two-level compound/base id check from
check_scalar_ids), but the comment here still describes the test as
verifying "base_id consistency" and refers to "unrelated base_id" on the
next line.

Looking at the function name and __description below:

>   */
>  __description("add_const base_id must be consistent for pruning")
>  __failure __msg("invalid variable-offset")
>  __naked void add_const_base_id_pruning(void)

and later at line 695:

>  	/* Runtime: R2.id=A, R4.id=C: base_ids A vs C inconsistent,
>  	 * pruning should have failed. */

Should these be updated to use current terminology, or does "base_id"
still have meaning in this context? The test itself still works correctly
after the patch, so this appears to be a documentation consistency
question rather than a functional issue.


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34506184282