Re: [PATCH bpf-next 02/11] bpf: do not intersect with current register range on clamp

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Sat Oct 24, 2026 at 6:57 AM UTC, Eduard Zingerman wrote:
> On Sat, 2026-10-24 at 00:41 +0000, bot+bpf-ci@kernel.org wrote:
>
> ...
>
>> Since bisection can land on this commit, could that change be folded into
>> this patch or ordered before it?
>
> Commits should remain separate for documentation purposes.
> Full test suite passes on both.
>
>> A related question about the end of the series.  cf18840bc068 only helps
>> when the current frame has no active loop.  Consider states inside an inner
>> loop that is entered again on the second iteration of a terminating outer
>> loop.  current_loop() finds the inner loop in both states, but its
>> entry_state differs, because handle_loop_entry_exit() splits a new one on
>> each entry.  So the EXACT check runs, and loop_stack_safe() does not
>> compare entry_state.
>> 
>> With the outer induction variable now the same on every outer iteration, a
>> program like the one below looks like it would still hit "infinite loop
>> detected" after cf18840bc068 (with the old code the outer induction
>> variable was [1..9] on the second outer iteration and the EXACT compare
>> failed):
>> 
>>     w1 = 1;
>>     *(u32 *)(r10 - 8) = r1;
>>     r6 = 0;
>> 1:  r7 = 0;
>> 2:  *(u32 *)(r10 - 4) = 1;   /* fp-8 spill -> STACK_MISC */
>>     r7 += 1;
>>     if r7 < 3 goto 2b;
>>     r6 += 1;
>>     if r6 < 10 goto 1b;
>>     r0 = *(u32 *)(r10 - 8);
>>     exit;
>> 
>> Is that case covered somewhere I missed?
>
> This example is valid. Need to relax the condition in the
> current_loop() or bpf_is_state_visited().

so you're going to respin it or follow up?

It's fine to ignore CI in patch 3.
We'll be removing states.c soon.