Hi, William,

Your analysis is correct. In this case, the error message could be improved.
In general, a message like this "back-edge from insn 240 to 219" indicates
a loop (back-edge ...).

Compiler probably should give a warning if it is BPF backend to indicate
there
are loops in the byte code. I will look into this.

Yonghong


On Tue, Apr 18, 2017 at 9:00 PM, William Tu via iovisor-dev <
[email protected]> wrote:

> Hi Mauricio,
>
> Thanks! Yes, I think like you said the compiler couldn't unroll in
> this case. Because we are passing memory address of i (&i) to a
> function, the function might change the value of 'i', which might
> change the number of loops. So compiler should disable unrolling.
>
> Regards,
> William
>
> On Tue, Apr 18, 2017 at 6:22 PM, Mauricio Vasquez
> <[email protected]> wrote:
> > Hi William,
> >
> > On 04/18/2017 06:54 PM, William Tu via iovisor-dev wrote:
> >>
> >> Hi,
> >>
> >> I found that if the loop variable "int i" is used in the map lookup as
> >> below:
> >> #pragma clang loop unroll(full)
> >>     for (i = 0; i < 8; ++i) {
> >>         struct bpf_flow_keys *mask;
> >>         mask = bpf_map_lookup_elem(&flow_mask, &i);
> >>         if (!mask)
> >>             break;
> >>     }
> >> Then the compiled BPF code does not unrolled the loop, causing errors:
> >> "back-edge from insn 240 to 219"
> >>
> >> A workaround for that is to declare another variable "int j", then I
> >> can pass the verifier.
> >>
> >> #pragma clang loop unroll(full)
> >>     for (i = 0; i < 8; ++i) {
> >>         int j = i;
> >>         struct bpf_flow_keys *mask;
> >>         mask = bpf_map_lookup_elem(&flow_mask, &j); // ---> use "j"
> >>         if (!mask)
> >>             break;
> >>     }
> >>
> >> Does anyone hit similar issue?
> >
> >
> > Yes, we hit exactly the same problem [1], at that time we thought it was
> > because of the missing "const" qualifier in the bpf_map_* helpers [2],
> > however we added it and the result was the same.
> >
> > Until now we don't know what is the cause of the problem, we continue to
> use
> > that workaround.
> >
> > Mauricio V,
> >
> > [1]
> > https://lists.iovisor.org/pipermail/iovisor-dev/2016-
> December/000560.html
> > [2]
> > https://lists.iovisor.org/pipermail/iovisor-dev/2016-
> December/000559.html
> >>
> >> Regards,
> >> William
> >> _______________________________________________
> >> iovisor-dev mailing list
> >> [email protected]
> >> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
> >>
> >
> _______________________________________________
> iovisor-dev mailing list
> [email protected]
> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Reply via email to