On Thu Sep 10, 2026 at 9:46 AM PDT, Vineet Gupta wrote:
> regs_exact() memcmp()s up to offsetof(id), so it does not see ->add_const,
> which sits past ->frameno. Compare it explicitly.
>
> Two cases go from accepted to rejected:
>
> old {r1.id=A, r2.id=A+delta} vs cur {r1.id=B, r2.id=B}
> old {r2.id=A+delta32} vs cur {r2.id=B+delta64}
>
> The first was rejected before this series -- the kind lived in ->id, so
> A+delta was a distinct idmap key -- and the previous patch lost that. The
> second was accepted before the series too, which is wrong: alu32 and alu64
> deltas differ in sync_linked_regs(), so the states are not
> interchangeable.
>
> ->delta is inside the memcmp() window and is cleared together with the
> kind, so either case needs a kind with delta 0, e.g. "r6 = r5; r6 += 0".
>
> Only states_equal(..., EXACT) and env->explore_alu_limits reach
> regs_exact() for a scalar; regsafe() compares kinds itself on the ordinary
> path. Neither is easy to drive from a test program, so no selftest.
>
> Signed-off-by: Vineet Gupta <[email protected]>
> ---
> v2: new. Splits out the comparison RFC 3/6 lost when the kind left
> ->id, which was raised on that patch.
>
> kernel/bpf/states.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/bpf/states.c b/kernel/bpf/states.c
> index d974baad37ee..5505d7aaeed0 100644
> --- a/kernel/bpf/states.c
> +++ b/kernel/bpf/states.c
> @@ -475,6 +475,7 @@ static bool regs_exact(const struct bpf_reg_state *rold,
> struct bpf_idmap *idmap)
> {
> return memcmp(rold, rcur, offsetof(struct bpf_reg_state, id)) == 0 &&
> + rold->add_const == rcur->add_const &&
This change should be in the patch 1 otherwise patch 1 is not correct?
