> On Jun 24, 2025, at 2:00 PM, Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Tue, 2025-06-24 at 20:50 +0000, Song Liu wrote: > > [...] > >>> Note, bpf_reg_state->id has to be reset on BPF_NEG otherwise the >>> following is possible: >>> >>> 4: (bf) r2 = r1 ; R1_w=scalar(id=2,...) R2_w=scalar(id=2,...) >>> 5: (87) r1 = -r1 ; R1_w=scalar(id=2,...) >>> >>> On the master the id is reset by mark_reg_unknown. >>> This id is used to transfer range knowledge over all scalars with the >>> same id. >> >> I think we should use "__mark_reg_known(dst_reg, 0);" here? > > That's an option, yes. > > [...] > >>> Nit: I'd match __log_level(2) output to check the actual range >>> inferred by verifier. >> >> I tried __log_level(2). However, this program is so simple that >> the verifier log is really simple: >> >> VERIFIER LOG: >> ============= >> processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 >> ============= >> >> So I didn’t include __log_level(2) here. > > When __log_level(2) is specified every instruction visited by verifier > should be printed in the log with range info etc. > E.g. see verifier_precision.c:bpf_cond_op_not_r10(). > > If that is not working for you could you please share a branch on gh > or something like that? Ah, I was assuming "test_progs -vv” is the same as __log_level(2), which is not accurate. Now I can see the log. Thanks, Song