On Fri, Jan 25, 2019 at 04:27:02AM +0000, Alexei Starovoitov wrote:
> 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 :)
Fair enough! But once you meet my challenge, the RCU CPU stall warning
code will challenge you to hit 21 seconds (or only three seconds given
an appropriately configured kernel). ;-)
Thanx, Paul
