On Tue, 2 Aug 2022 at 00:46, Alexei Starovoitov <ast@xxxxxx> wrote:
>
> On 7/22/22 11:34 AM, Dave Marchevsky wrote:
> > if (__is_pointer_value(false, reg)) {
> > + if (__is_iter_end(reg) && val == 0) {
> > + __mark_reg_const_zero(reg);
> > + switch (opcode) {
> > + case BPF_JEQ:
> > + return 1;
> > + case BPF_JNE:
> > + return 0;
> > + default:
> > + return -1;
> > + }
> > + }
>
> as discussed the verifying the loop twice is not safe.
> This needs more advanced verifier hacking.
> Maybe let's postpone rbtree iters for now and resolve all the rest?
> Or do iters with a callback, since that's more or less a clear path fwd?
>
Can you elaborate a bit on what you think the challenges/concerns are
(even just for educational purposes)? I am exploring a similar
approach for one of my use cases.
On Tue, 2 Aug 2022 at 00:46, Alexei Starovoitov <ast@xxxxxx> wrote:
>
> On 7/22/22 11:34 AM, Dave Marchevsky wrote:
> > if (__is_pointer_value(false, reg)) {
> > + if (__is_iter_end(reg) && val == 0) {
> > + __mark_reg_const_zero(reg);
> > + switch (opcode) {
> > + case BPF_JEQ:
> > + return 1;
> > + case BPF_JNE:
> > + return 0;
> > + default:
> > + return -1;
> > + }
> > + }
>
> as discussed the verifying the loop twice is not safe.
> This needs more advanced verifier hacking.
> Maybe let's postpone rbtree iters for now and resolve all the rest?
> Or do iters with a callback, since that's more or less a clear path fwd?
>
