On 1/24/19 6:38 PM, Alexei Starovoitov wrote: >> For programs created with CAP_SYS_ADMIN, >> things get more tricky because you can create your own functions and >> call them repeatedly; I'm not sure whether the pessimal runtime there >> becomes exponential, or whether there is some check that catches this. > I think you're referring to bpf-to-bpf calls. > The limit it still the same. 4k per program including all calls. > tail calls are not allowed when bpf-to-bpf is used. So no 32 multiplier.
Jann, I think you meant main: call A call A call A exit A: call B call B call B exit B: call C ... scenario when everything fits into 4k? Would be great if you can construct such test while we're fixing the rest of the issues brought up in this thread. It will definitely be no more than BPF_COMPLEXITY_LIMIT_INSNS which is 128k, but I wonder what will be the actual number of executed insns. I think such clever constructed sequence can actually hit 128k executed too. It would be awesome test to add to test_verifier.c We have some of such pushing-the-boundary tests in lib/test_bpf.c that are generated in assembler. The longest takes 23853 nanoseconds, but clever bpf2bpf call hack like above with map_update call in the leaf function should certainly take much longer. I accept Paul's challenge to try to get such fancy bpf prog to take 100 millseconds :)
