On 9/12/26 11:51 AM, Alexei Starovoitov wrote:
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?
Will do - it was one of the open questions in v2. Thx, -Vineet
